Comments 13
А зачем вообще использовать rebase? Ведь установлено же что rebase это — абсолютное зло:
1. habrahabr.ru/post/179123/
2. habrahabr.ru/post/179673/
3. geekblog.oneandoneis2.org/index.php/2013/04/30/please-stay-away-from-rebase
Nuff said.
1. habrahabr.ru/post/179123/
2. habrahabr.ru/post/179673/
3. geekblog.oneandoneis2.org/index.php/2013/04/30/please-stay-away-from-rebase
The whole reason to use a VCS is to have it record your history. Rebasing destroys your history, and therefore destroys the point of using a VCS.
Nuff said.
Да в данных ситуациях, которые рассматриваются в статьях, это верно, изменять историю не очень хорошо. Но мы ее исправляем только для ветки релиза, и только для быстрого отката задачи, при этом история все равно сохраняется (в старой ветке), так как после ребейза мы создаем новую релизную ветку.
Цитата верна, кроме тех случаев когда изменение истории является меньшим из зол. Например когда вы сливаете вместе несколько веток прежде чем влить их в
master и в случае обнаружения проблем в одной из веток гораздо удобнее с помощью git rebase один раз убрать ее и отдать в доработку нежели использовать git revert несколько раз.
Отличная статья! Задача непростая поставлена, и решение хорошее! Молодцы!
Сколько задач обычно попадает в релиз? Не будет ли проще пересоздать релиз и заново вмержить только нужные задачи в автоматическом режиме? Вероятность конфликтов при этом уменьшится.
В релиз может попадать от одной до нескольких десятков задач. В среднем ежедневно уходит 20-30 задач в одну выкладку. В обе выкладки, около 50 задач, соответственно.
Вы правы, перемерживание всех задач в новый билд это тоже вариант. Но помимо смерженных веток в ветке релиза могут быть фиксы. Например, фиксы багов интеграции задач друг с другом. В случае перемерживания задач такие фиксы могут потеряться. А в случае удаления мержевого коммита из ствола, удалится только этот коммит. Остальные правки останутся в ветке.
В том числе и поэтому мы проверяем при решении конфликтов отката (в алгоритме скрипта про это написано), нет ли правок откатываемых файлов в других коммитах, когда проходит ребейз. Чтобы исключить оставшиеся патчи на откатываемую задачу, например, после отката задачи.
Вы правы, перемерживание всех задач в новый билд это тоже вариант. Но помимо смерженных веток в ветке релиза могут быть фиксы. Например, фиксы багов интеграции задач друг с другом. В случае перемерживания задач такие фиксы могут потеряться. А в случае удаления мержевого коммита из ствола, удалится только этот коммит. Остальные правки останутся в ветке.
В том числе и поэтому мы проверяем при решении конфликтов отката (в алгоритме скрипта про это написано), нет ли правок откатываемых файлов в других коммитах, когда проходит ребейз. Чтобы исключить оставшиеся патчи на откатываемую задачу, например, после отката задачи.
Сначала нужно было дочитать;(
Поробоуйте использовать вот это: github.com/affinitybridge/git-bpf
Вписывается в ваш сценарий использования на 100%:
$ git recreate-branch -a release -b release_r1 -x BFG-9000-broken
Вписывается в ваш сценарий использования на 100%:
$ git recreate-branch -a release -b release_r1 -x BFG-9000-broken
Sign up to leave a comment.
Git rebase «по кнопке»