Какой должен быть git workflow для сохранения линейной истории master'a?

Question

[wagant]

Подскажите, пожалуйста, наиболее правильный git workflow при котором бы сохранялась линейная история master'a. Вот то, что я мог придумать.

Правила:
1. В бранч master нельзя коммитить. В него можно только мержить.
2. В процессе разработки есть две роли: (1) простой разработчик и (2) координатор.

Процесс разработки:
1. Разработчик создает ветку topic от ветки master.
2. Пишет код в ветке topic.
3. Периодически выполняет merge из master'а в topic. При этом topic уже становится нелинейным, и это правильно.
4. Как только он закончил разрабатывать код в topic он сообщает координатору, что код готов.
5. Координатор выполняет code review в бранче topic. Если нашел ошибки, он сообщает разработчику и тот исправляет их в бранче topic.
6. Если координатор не нашел ошибок в бранче topic он выполняет rebase topic'а над master, после чего выполняет fast forward merge topic'а в master.
7. Сообщает разработчику, что мерж выполнен и бранч topic можно удалить.

Преимущества:
1. Мы сохраняем линейную структуру бранча master.

Недостатки:
1. После ребейза брача topic координатором он становится невалидным у разработчика. И это мне не нравится.

В общем, вопрос такой. Есть ли более правильный процесс разработки с сохранением линейной структуры master'а?

Answer 1

[jcmvbkbc]

Пара вопросов:

1. В бранч master нельзя коммитить. В него можно только мержить.

Если с мастером всё равно работает только координатор, то какая разница, как он будет его пополнять?

3. Периодически выполняет merge из master'а в topic. При этом topic уже становится нелинейным, и это правильно.

А зачем? Почему бы ему самому не ребейзить свою ветку на нужное место мастера или не выдёргивать оттуда нужные коммиты через cherry-pick?

Запрет на ребейз перед мёржем в апстрим, например в линуксе, связан с тем, что код должен быть уже протестирован в топике, и после ребейза его придётся тестировать снова. Кроме того, если в мастере и в топике были конфликтующие изменения, то лучше их зафиксировать в одном месте — в точке мёржа топика, чем размазывать по разным конфликтующим коммитам топика при его ребейзе.

Comments

[wagant]

Почему бы ему самому не ребейзить свою ветку на нужное место мастера или не выдёргивать оттуда нужные коммиты через cherry-pick?

Разработчик пишет код в свой topic бранч и периодически его показывает остальной команде. Для этого он выполняет push в origin. Кроме этого он периодически проверяет не изменился ли master и если изменился, то делает merge из master'а в свой topic. На этом этапе мне все нравится. Topic доступен для всей команды и актуален по сравнению с master.

Но вот как правильно его обратно смержить в master? Если делать обычный merge, то история в master'е будет сумасшедшей. А если делать rebase, то у других topic станет невалидным.

[jcmvbkbc]

у других topic станет невалидным

Кому нужен старый топик, после того как он будет замёржен в мастер? Базироваться нужно на мастере.
Если всё-таки пришлось ветвить свой топик от чужого топика, то нужно свой переносить на мастер после мёржа первого топика. git rebase --onto с этим отлично справляется.

[wagant]

В общем да, согласен. Действительно ничего страшного в невалидности топика после мержа нет. Спасибо!

Answer 2

[Валентин]

git add --al
git stash
git pull
git stash apply
git commit -am «comment»
git push

Комитить в только в мастер, ни каких ветвлений. Для 2-3 человек — самое то.

Comments

[jcmvbkbc]

Может тогда уж проще, git commit -as; git pull --rebase; git push?

Answer 3

[asm0dey]

habrahabr.ru/post/147260/

Comments

[wagant]

Спасибо за ссылку! Я тут поискал, больше всего мне понравилось вот это описание Merge or Rebase.

[asm0dey]

Для гита есть крутое расширение — git flow, которое автоматизирует работу с Successful Branching Model, merge или rebase там можно выбирать, по умолчанию вроде скваш ребэйз.

[wagant]

Ага, я попробую.