Комментарии 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.
+1
Да в данных ситуациях, которые рассматриваются в статьях, это верно, изменять историю не очень хорошо. Но мы ее исправляем только для ветки релиза, и только для быстрого отката задачи, при этом история все равно сохраняется (в старой ветке), так как после ребейза мы создаем новую релизную ветку.
+7
Цитата верна, кроме тех случаев когда изменение истории является меньшим из зол. Например когда вы сливаете вместе несколько веток прежде чем влить их в
master
и в случае обнаружения проблем в одной из веток гораздо удобнее с помощью git rebase
один раз убрать ее и отдать в доработку нежели использовать git revert
несколько раз.+2
Отличная статья! Задача непростая поставлена, и решение хорошее! Молодцы!
+3
Сколько задач обычно попадает в релиз? Не будет ли проще пересоздать релиз и заново вмержить только нужные задачи в автоматическом режиме? Вероятность конфликтов при этом уменьшится.
0
В релиз может попадать от одной до нескольких десятков задач. В среднем ежедневно уходит 20-30 задач в одну выкладку. В обе выкладки, около 50 задач, соответственно.
Вы правы, перемерживание всех задач в новый билд это тоже вариант. Но помимо смерженных веток в ветке релиза могут быть фиксы. Например, фиксы багов интеграции задач друг с другом. В случае перемерживания задач такие фиксы могут потеряться. А в случае удаления мержевого коммита из ствола, удалится только этот коммит. Остальные правки останутся в ветке.
В том числе и поэтому мы проверяем при решении конфликтов отката (в алгоритме скрипта про это написано), нет ли правок откатываемых файлов в других коммитах, когда проходит ребейз. Чтобы исключить оставшиеся патчи на откатываемую задачу, например, после отката задачи.
Вы правы, перемерживание всех задач в новый билд это тоже вариант. Но помимо смерженных веток в ветке релиза могут быть фиксы. Например, фиксы багов интеграции задач друг с другом. В случае перемерживания задач такие фиксы могут потеряться. А в случае удаления мержевого коммита из ствола, удалится только этот коммит. Остальные правки останутся в ветке.
В том числе и поэтому мы проверяем при решении конфликтов отката (в алгоритме скрипта про это написано), нет ли правок откатываемых файлов в других коммитах, когда проходит ребейз. Чтобы исключить оставшиеся патчи на откатываемую задачу, например, после отката задачи.
0
Сначала нужно было дочитать;(
0
Поробоуйте использовать вот это: 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
0
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Git rebase «по кнопке»