Модель ветвления для тимбилдов через git

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

В настоящее время мы используем следующий подход для перемещения нашей функции с локального на главный.

  • Мы создаем ветвь функции из мастера.
  • Реализуйте эту функцию и отправьте изменения в master как запрос на слияние.

Проблема с этим подходом заключается в том, что если есть какие-либо проблемы совместимости/слияния с кодом, который упускается из виду во время слияния, в конечном итоге создает проблемы во время сборки или развертывания; влияет на количество команд, ожидающих работы/тестирования последнего кода в среде.

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

Как бы то ни было, у меня есть некоторое замешательство относительно веток функций, которые мы будем создавать.

  • В начале спринта я создаю и отправляю ветку интеграции с мастера, а в последующие дни я перебазирую ветку интеграции с мастера. Мы развертываем эту ветку на наших командных серверах.
  • После выбора функции для работы мы создаем ветвь функции из мастера, реализуем функцию там, а затем, когда функция завершена, выбираем вишни, которые фиксируются в ветке интеграции.
  • После завершения тестирования на командных серверах мы создаем запрос на слияние из ветки функций, который будет объединен на главном сервере.

Эта модель верна или мы что-то упускаем?

Спасибо


git branching-and-merging branching-strategy tfsbuild
person Suraj Sharma    schedule 26.11.2019    source источник

Ответы (1)


arrow_upward
1
arrow_downward

В моем понимании выигрыш будет минимальным, если вообще будет... Поясню:

Ветки в git — это не более чем именованные указатели на какой-то идентификатор коммита, и вы сами определяете политику работы с ветками.

Итак, в начале спринта вы создаете указатель на мастера, который (я понимаю из вопроса) быстро перемещается и сильно меняется во время спринта. Ветка интеграции перебазируется из мастера и в основном выглядит как мастер + функции, которые начались и закончились во время спринта (для ясности я буду называть их небольшими функциями).

Ветка Feature, которую вы описываете, взята из master, а не из ветки интеграции, хорошо, скажем, в начале спринта.

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

Теперь мейнтейнеру фичи все равно придется разрешать конфликты - тот же набор конфликтов, что был у вас при первоначальном подходе + набор конфликтов из "мелких фич"

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

Основываясь на этих мыслях, позвольте мне предложить альтернативный подход:

Я буду полагаться на следующие «претензии», если хотите:

  1. Git не «поощряет» долгоживущие ветки.
  2. Функциональные ветки в порядке, но сопровождающий функциональной ветки должен сделать ее актуальной.

Мой подход:

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

  2. Когда вы работаете над функцией, часто выполняйте ребазинг из мастера и поддерживайте ветку функции в «актуальном состоянии». Чем чаще вы это делаете - тем меньше вероятность столкновений.

  3. Когда ветка будет готова - снова перебазируйте из мастера, чтобы она была актуальной, и нажмите на тесты или что-то еще, а затем слейте. Предполагая, что вы сделали «2», этот шаг будет легким.

Примечание о «2»: функциональная ветвь принадлежит только вам (при условии, что только вы работаете над этой функцией), поэтому эти перебазирования безвредны и повлияют только на ваши локальные коммиты. Если вам нужно сохранить результаты в удаленном репо, то SHA1 вашего коммита будут меняться каждый раз, когда вы выполняете перебазирование. В этом случае вы можете «подавить» исходную ветвь, используя git push -f

person Mark Bramnik    schedule 26.11.2019
comment
Марк, спасибо за подробное объяснение, но в пункте 3, когда вы говорили о переходе к тестам, вы имели в виду ветку интеграции? - person Suraj Sharma; 04.12.2019
comment
О, я хотел отправить готовую ветку для слияния с мастером. Иногда существуют тесты, которые CI должен запускать в ветке, чтобы подтвердить, что эта ветка может быть передана в master. - person Mark Bramnik; 04.12.2019