Git стратегия ветвления - запросы на извлечение создают коммиты слияния, при которых ветви выглядят по-разному, в то время как файлы равны - PullRequest
2 голосов
/ 24 февраля 2020

В моем текущем проекте у нас есть три ветви; master, dev и hotfix.

Когда будет реализована новая функция, разработчик создаст новую feature_branch из master. Когда функция будет готова для проверки и тестирования, разработчик создаст запрос на извлечение для объединения feature_branch в dev. Когда это объединено, среды разработки и тестирования будут созданы и развернуты (из ветви dev). В этой среде будет проведено некоторое тестирование и произведен контроль качества.

Как только тестирование будет завершено, разработчик откроет запрос на извлечение из feature_branch в master. После слияния с master начнется сборка и развертывание для подготовки и производства.

Это работает нормально, единственная проблема заключается в том, что различные коммиты слияния, сделанные слиянием по запросу извлечения, делают так, что ветви Выглядит иначе. В представлении ветви в Azure DevOps (которое является нашей средой DevOps), ветка dev выглядит на 1 коммит позади и на 1 коммит перед веткой сравнения (которая является веткой master). Это связано с тем, что ветвь dev имеет коммит, которого нет у основной ветки (объединенный PR из feature_branch в dev), и отсутствует тот, который есть у ветви master (объединенный PR из feature_branch в master).

Есть ли хороший способ сделать так, чтобы ветви dev и master выглядели равными здесь?

Идея этих трех ветвей состоит в том, что если есть ошибка, мы можем создать bugfix_branch из ветви master и открыть запрос на извлечение из bugfix_branch в ветку hotfix. Объединение с веткой hotfix создаст и развернет тестовую среду, в которой исправление ошибки можно протестировать отдельно. Как только исправление ошибки будет одобрено, разработчик откроет запрос на извлечение из bugfix_branch в master.

Ветка hotfix также будет отличаться от dev и master.

Заранее спасибо за любую помощь.

1 Ответ

2 голосов
/ 24 февраля 2020

Предположим, следующая история:

* 99a48ee (feature_branch) Add feature a
* 499665a (HEAD -> dev, master) Initial commit

Слияние с feature_branch с dev создаст коммит слияния:

git merge --no-ff feature_branch
*   8aa6422 (HEAD -> dev) Merge branch 'feature_branch' into dev
|\  
| * 99a48ee (feature_branch) Add feature a
|/  
* 499665a (master) Initial commit

После завершения тестирования, разработчик откроет пулл-запрос из feature_branch в master.

Это необычный бит. Вы получите следующее:

git checkout master
git merge --no-ff feature_branch
*   9a3f2e7 (HEAD -> master) Merge branch 'feature_branch'
|\  
| | *   8aa6422 (dev) Merge branch 'feature_branch' into dev
| | |\  
| |/ /  
|/| /   
| |/    
| * 99a48ee (feature_branch) Add feature a
|/  
* 499665a Initial commit

Это уже выглядит неправильно! dev теперь [ahead 1, behind 1], потому что он включает в себя 8aa6422 и пропускает 9a3f2e7.

  dev            8aa6422 [ahead 1, behind 1] Merge branch 'feature_branch' into dev
  feature_branch 99a48ee [behind 1] Add feature a
* master         9a3f2e7 Merge branch 'feature_branch'

Вместо того, чтобы объединять ветку объектов в master, нужно было объединить dev в master. Давайте попробуем это с состоянием хранилища перед последним слиянием, описанным выше.

git reset --hard HEAD^  # rollback the merge we just did above
git merge --no-ff dev
*   c59be01 (HEAD -> master) Merge branch 'dev'
|\  
| *   8aa6422 (dev) Merge branch 'feature_branch' into dev
| |\  
|/ /  
| * 99a48ee (feature_branch) Add feature a
|/  
* 499665a Initial commit

Это выглядит лучше, без перекрывающихся строк! dev больше не впереди и сзади, а позади, так как у него нет слияния с мастером.

  dev            8aa6422 [behind 1] Merge branch 'feature_branch' into dev
  feature_branch 99a48ee [behind 2] Add feature a
* master         c59be01 Merge branch 'dev'

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

Если вы действительно хотите, чтобы они были одинаковыми, вам нужно будет выполнить ускоренное слияние вместо создания коммита слияния. Давайте снова перемотаем и посмотрим, как это выглядит:

git reset --hard HEAD^  # rollback again
git merge dev           # without --no-ff will default to --ff (fast forward)
*   8aa6422 (HEAD -> master, dev) Merge branch 'feature_branch' into dev
|\  
| * 99a48ee (feature_branch) Add feature a
|/  
* 499665a Initial commit

Теперь master и dev идентичны!

  dev            8aa6422 Merge branch 'feature_branch' into dev
  feature_branch 99a48ee [behind 1] Add feature a
* master         8aa6422 Merge branch 'feature_branch' into dev
...