Прогнозирование конфликтов слияния между ветвями объектов при их слиянии в основной ветке - PullRequest
Новая
       13

Прогнозирование конфликтов слияния между ветвями объектов при их слиянии в основной ветке

0 голосов
/ 24 апреля 2020

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

merge feature1 into master => OK
merge feature2 into master => OK
merge feature3 into master => CONFLICTS!

Не было добавлено ни одного коммита, но конфликт слияния все еще существует, потому что Feature3 конфликтует с Feature1. и / или feature2.

Существует ли инструмент для прогнозирования этого конфликта слияния (чтобы увидеть, какие ветви компонентов будут создавать конфликт слияния)? Если бы я мог предсказать это, я мог бы разделить только функции feature1 и feature3 в основной ветке.

Спасибо!

1 Ответ

1 голос
/ 24 апреля 2020

Способ прогнозирования конфликта слияния состоит в том, чтобы выполнить слияние. 1 Для этого используйте временную ветвь: 

git checkout -b test master
git merge feature1
git merge feature2
git merge feature3

Если все прошло хорошо, слияния работают. Теперь вы можете, если хотите, использовать это окончательное объединение в качестве результата для master, выполнив операцию fast-forward , чтобы переместить master вверх для соответствия test: 

git checkout master
git merge --ff-only test   # --ff-only means "fail if fast-forward is not possible"

или просто удалить ответвление test, если вы не хотите этого делать и / или слияние не удалось. Если слияние не удалось, используйте git merge --abort, чтобы выйти из него, как в сноске 1, или git reset --hard (что делает то же самое). Затем используйте git checkout master и git branch -D test: 

git merge --abort          # if needed
git checkout master
git branch -D test

Единственная причина использовать отдельную ветку test, указанную выше, состоит в том, чтобы избежать перемещения master, пока мы не выполним все три слияния. Но поскольку имена ветвей являются частными для каждого репозитория, для этого никогда не требуется требование : вы можете просто выполнить слияние, а затем откатиться (с git reset --hard) к предыдущему состоянию, если вы этого не сделаете нравится результат. Только не git push коммиты или не делайте их доступными для git fetch, пока не получите желаемый результат.

1 Вы можете выполнить тестовое слияние без примите коммит, если хотите, используйте git merge --abort, чтобы представить, что вы никогда не запускали тест. Но это не работает, когда вам нужно сделать более одного слияния, как в случае с вашим вопросом.

Осьминог слияния

Однако есть еще один вариант, который Git звонит осьминог сливается . (Примечание: Вы не можете сделать это с помощью GitHub, и, вероятно, не с некоторыми другими веб-интерфейсами.) Чтобы выполнить слияние осьминога, которое объединяет все три функции в master одновременно: 

git checkout master
git merge feature1 feature2 feature3

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

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

...