Git и заставляет принимать изменения из другой ветки - PullRequest
1 голос
/ 08 апреля 2019

Я пытаюсь объединить ветку в master, но хочу, чтобы все изменения из другой ветки вступили в силу, несмотря ни на что, но не знаете, как это сделать?Основная проблема заключается в том, что мы заканчиваем конфликтами слияния в 50 файлах, где нас не волнует предыдущее состояние мастера.

История: Основная ветвь была сохранена для выпуска в 2018 году,в то время как работа для выпуска 2019 года была сделана в другой ветке.Изменения в 2019 году являются сложными и требуют отбрасывания значительной части изменений 2018 года из-за воздействия изменений зависимостей среды выполнения.Теперь мы хотим взять все изменения с 2019 года и сделать их новым государством.

То, что я пробовал до сих пор (как отдельные попытки):

git merge 2019-release
git merge -X theirs 2019-release
git merge -s recursive -X theirs 2019-release

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

Хотите знать, следует ли использовать подход к мастеру с использованием выжженной земли (очистка всех файлов и фиксацию) с последующим слиянием, - альтернативный подход?

Я попытался осмотреть Stack Overflow, но не нашел ответа, который, кажется, правильно решает проблему.

Любые предложения будут оценены?

1 Ответ

1 голос
/ 08 апреля 2019

То, что вы ищете, близко к последнему, которое вы пробовали.

git merge -X ours (или даже git merge -s recursive -X ours) автоматически разрешает конфликты с использованием стороны ours. ( документ )

git merge -s ours принимает все из принимающей ветви, конфликтует или нет.

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

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


и так

# we have to work from the 2019-release side since there is no theirs version for -s
git checkout 2019-release
git merge -s ours master

# at this point we have to reflect the operation on master
# (the second merge is just a fast-forward)
git checkout master
git merge 2019-release

Это займет все со стороны 2019-release и все равно пометит операцию как слияние, хотя некоторые могут утверждать, что это технически перезапись.

...