Лучше ли объединять «часто» или только после завершения делать большое объединение ветвей функций?

Скажем, разрабатываются несколько веток, AиB , а также пошаговый ветвь «исправлена ошибка» C.

Сейчас Cуже «закончен» и объединен в мастера.Aи Bвсе еще находятся в разработке и не будут исправлены до (возможно), когда другая ветвь исправления ошибок будет объединена с главной.

Является ли хорошей идеей Cкак можно скорее объединить новые ветки функций? Чтобы новые функции оставались как можно masterближе? Или лучше позволить новой функции развиваться в их собственном «мире», сливаясь с мастером только после того, как они закончат работу?

В любом случае будут конфликты, поэтому на их устранение нужно потратить время.

Чем дольше ветка живет, тем больше она способна отклониться от основной ветви, и чем сложнее, тем сложнее будет окончательное слияние, когда оно будет окончательно завершено. Десять небольших конфликтов легче разрешить, чем один крупный конфликт, и они могут фактически помешать разработчикам дублировать или тратить усилия. Учитывая , что, вы должны слиться masterв Aи Bрегулярно; Один раз в день это довольно распространенная рекомендация, хотя, если у вас много активности в ваших ветках, вы можете объединяться несколько раз в день.

В дополнение к упрощению разрешения конфликтов, вы упомянули Cветку об исправлениях ошибок. Как разработчик, я бы хотел, чтобы в моей ветке были все последние исправления ошибок, чтобы я не повторял поведение, которое привело к ошибке, или писал тесты на основе ошибочных данных.

В любом случае будут конфликты, поэтому на их устранение нужно потратить время.

Если вы знаете, что будут конфликты, вы можете выбрать другую стратегию ветвления. Храните несколько изменений в одном и том же файле (файлах) в одной и той же ветке, когда это возможно, и вы уменьшаете или устраняете количество конфликтов. Реорганизовать истории, чтобы они были максимально независимыми, и переработать ветки, возможно, для охвата нескольких историй (ветвь, функция и история не всегда взаимозаменяемы).

Предполагая, что вы намерены в конечном итоге объединить A, B обратно в master и поддерживать единую кодовую базу, никогда не стоит слишком сильно отклоняться от master. Слишком долгое отклонение от master, особенно когда исправления ошибок и другие разработки сливаются с master, поскольку A, B разрабатываются, безусловно, вызовет конфликты.

Я бы рассмотрел стратегии, аналогичные следующим

1. Кто бы ни отвечал за A, B должен внимательно следить за мастером и объединяться в любых изменениях.
2. Еще лучше, если у вас есть автоматизация сборки и тестирования, убедитесь, что A, B объединены в master, и проходите тесты каждую ночь.
3. Исходя из вашего комментария к другому ответу, кажется, что A, B может занять некоторое время, чтобы развиться. В этом случае вы можете даже подумать о том, чтобы A, B также слились друг с другом, так что в итоге у вас не возникнет серьезных проблем при объединении обоих обратно в master.
4. На более высоком уровне подумайте, зачем вам нужны 2 отдельные линии долгой разработки. Не могли бы вы разбиться на более мелкие слияния? Не могли бы вы разбить на отдельные микро сервисы?

Обычно часто лучше, чем массивный.

Меньшие, более частые запросы на тягу почти всегда лучше.

Я начал использовать флаги конфигурации в первую очередь для того, чтобы я мог выполнять ранние меньшие запросы на извлечение, чтобы, в свою очередь, легче объединить код, но оставить функцию отключенной. Чем меньше запрос на извлечение, тем проще просмотреть код, даже если общее количество запросов на извлечение больше. Большинство людей любого рода не смогут делать содержательные обзоры массовых запросов на получение данных. Это просто слишком сложно для умственной памяти, чтобы понять все возможные последствия масштабного изменения кода.

Создание флага конфигурации требует дополнительных затрат, так что для небольших функций оно того не стоит. Но тогда ваш пул-запрос в любом случае будет маленьким.

Однако могут быть ситуации, когда функция должна быть выпущена сразу. Даже тогда, возможно, было бы лучше сделать меньшие запросы на удаление для другой ветви, созданной для этой цели.

Большинство моих коллег стонут, когда кто-то создает массивный запрос на удаление, и по большей части это правильно.

Также обратите внимание, что иногда мне нужно, чтобы вишня выбирала коммиты в отдельных ветках. Если то, что должно быть собрано вишней, может быть помещено в один коммит, это облегчает перемещение его в другие ветви. Это тот случай, когда на самом деле лучше иметь немного коммитов, но это не совсем стандартный процесс, если вы выбираете вишню.

В «Рефакторинге» Мартина Фаулера совет, который он дает, никогда не позволяет ветке отделяться от хозяина дольше, чем на один день. IIRC, вы должны внести небольшое изменение, проверить, чтобы убедиться, что вы ничего не сломали, а затем объединить его обратно.

Другой вариант для действительно долгоживущих изменений, которые могут быть закончены, но не готовы к использованию, - это поместить их за флаг функции, чтобы их можно было объединить с мастером, но не было риска что-либо сломать. Затем, когда они будут готовы к использованию, флаг функции может быть удален.