Мерзавец поток сливаться вниз / влево постоянно

Question

Поток Git гарантирует, что изменения в master и release в конечном итоге окажутся в разработке:

• Исправления ветвятся от мастера и объединяются, чтобы развиваться. Если есть активная ветвь релиза, она объединяется там и распространяется только для разработки после того, как релиз объединен с мастером и разработчиком.

• Изменения в выпуске объединяются для разработки только после завершения выпуска

Интересно, почему происходит задержка до завершения релиза? Разве не было бы намного проще просто объединить мастер с выпуском и разработкой всякий раз, когда происходит изменение к мастеру, и выпускать для разработки, когда выпускаются изменения?

Таким образом, я сразу получу изменения, отраженные во всех соответствующих ветках, и мне не нужно будет думать о том, что объединять, где и когда.

Единственное объяснение, которое я мог придумать, заключается в том, что git flow решил, что менее частые слияния перевешивают выгоду от наличия обновленной / синхронизированной базы кода между филиалами.

Answer 1

Проблема в том, что develop для: ветка интеграции для тестирования функций вместе.
Добавление активного master (и его исправление) будет вмешиваться в интеграцию.

Вот почему я предпочитаю использовать gitworflow (который я здесь представляю): вы можете перебазировать любой feature ветвь сверху master (где исправление может быть объединено в любое время).
Опровергая ваши feature филиал, вы воспроизводите свои изменения поверх последних master (и его исправление).

Позже вы можете объединить любой feature филиал нужноnext"(develop ветка)

Наконец, когда вы знаете, какую ветвь функций вы выбрали для следующего выпуска, вы объединяете (снова) те feature ветви к master,

Answer 2

Git Flow действительно поддерживает то, что вы просите. К счастью, одна из ваших предпосылок ошибочна:

изменения в выпуске объединяются для разработки только после завершения выпуска

На самом деле это не так. Вам разрешено (и поощряется) объединять любые изменения в ветке так часто, как вам нужно. Обратите внимание, что на графике стратегии ветвления есть стрелки от зеленых коммитов до завершения. Существует также пузырь комментариев, в котором говорится:

Исправления из отн. ветвь может быть непрерывно объединена обратно в develop.

В моей организации наши релизные ветки живут около 7-10 дней, и я бы сказал, что в среднем мы объединяемся обратно по крайней мере один раз до завершения. Так что для исправлений, как только они объединены в , не стесняйтесь объединять их обратно, когда это имеет смысл.

В качестве связанного примечания: при завершении я предпочитаю объединяться в , а затем в . (Вместо в .) Это дает 2 преимущества:

1. Если вы не сливаетесь в , то после того, как у вас будет много выпусков до исправления, когда вы, наконец, создадите , при слиянии с ним вы принесете с собой кучу старых коммитов слияния, которые сидели на . Это может добавить путаницы.
2. Всегда, когда существует ветвь, вы хотите быть уверены, что все находится в . Если вы этого не сделаете, вы можете случайно удалить исправление, которое кто-то завершил, но забыл слить обратно в . Возможно, самый простой способ автоматизировать это — проверить, что HEAD находится в . Но это может быть правдой, только если вы объедините вернуться к (или вернуться к если он существует и вы только что завершили ).