Рабочий процесс: git с ветками функций, перебазированием, запросами на вытягивание (не проект с открытым исходным кодом)

У нас есть 5 разработчиков в команде, которые регулярно (ежедневно) отправляют пулл-реквесты на мастер-ветку одного репо. Типичный рабочий процесс выглядит следующим образом:

  • Клонировать репозиторий с сервера
  • Создать ветку локальной функции из главной ветки
  • Вносите изменения, фиксируйте, итерируйте, пока не закончите
  • Перебазировать на основную ветку (фиксация сквоша)
  • Отправить на сервер
  • Отправить запрос на включение

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

Должен быть лучший способ, верно?


git bitbucket pull-request git-workflow feature-branch
person David Wasser    schedule 04.05.2021    source источник
comment
Конечно, есть.... не требуйте, чтобы люди были в курсе последней версии мастера, чтобы иметь возможность слияния. Это что-то, что вы настроили? Потому что это вообще не требование git.   -  person eftshift0    schedule 04.05.2021
comment
@eftshift0 Мы используем Bitbucket, и он настроен следующим образом. Спасибо за предложение, я могу поговорить с командой, которая настроила его, чтобы проверить плюсы и минусы.   -  person David Wasser    schedule 04.05.2021

Ответы (1)


arrow_upward
0
arrow_downward

В Bitbucket доступны следующие стратегии слияния. Похоже, ваша команда выбрала либо «Только перемотка вперед», либо «Сквош, только перемотка вперед». Это отклонит PR, если он не полностью перебазирован, и, как вы заметили, это раздражает, когда PR выстроены в очередь.

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

Примечание: я лично предпочитаю то, что некоторые другие инструменты называют полулинейным слиянием, что было бы эквивалентно параметру BitBucket Rebase, merge. Это вызывает коммит слияния, что хорошо, так как вы можете видеть все коммиты, связанные с этим PR, и позволяет вам просматривать историю --first-parent, которая показывает фактические изменения, внесенные в ветку master. Но в вашем случае, если все сжимаются в одну фиксацию для каждого PR, то, возможно, для вас не будет никакой выгоды. Но если вы когда-нибудь решите разрешить несколько коммитов в одном PR, это может склонить чашу весов в этом направлении.

person TTT    schedule 04.05.2021