Git и принуждение к принятию изменений из другой ветки
Я пытаюсь объединить ветку с мастером, но хочу, чтобы все изменения из другой ветки вступили в силу, несмотря ни на что, но не знаю, как это сделать? Основная проблема заключается в том, что мы получаем конфликты слияния в 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, но не нашел ответа, который, кажется, правильно решает проблему.
Мы ценим любые предложения?
Я пробовал простой git rebase <branch>, но он тоже сталкивается с конфликтами. В настоящее время я пытаюсь выяснить, есть ли варианты, которые я должен передать в этом сценарии.
Ответы 1
То, что вы ищете, близко к последнему, который вы пробовали.
git merge -X ours (или даже git merge -s recursive -X ours) автоматически разрешает конфликты, используя ours сторону. (документ)
git merge -s ours берет все из принимающей ветки, конфликтует она или нет, тем самым полностью отбрасывая изменения со стороны theirs.
Как ни странно, соответствующие абзацы на странице имеют одинаковую якорную ссылку, должно быть небольшая ошибка, но обязательно проверьте обе записи и сравнить. Я не мог связать наиболее подходящий, так как он также указывает на другой, но говорит:
This resolves any number of heads, but the resulting tree of the merge is always that of the current branch head, effectively ignoring all changes from all other branches. It is meant to be used to supersede old development history of side branches. Note that this is different from the -Xours option to the recursive merge strategy.
И так
# 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 и все равно пометит операцию как слияние, хотя некоторые могут утверждать, что технически это перезапись.
git говорит: error: Merging is not possible because you have unmerged files. после запуска git merge -s ours master
Кажется, это указывает на то, что у вас уже было текущее слияние. Если нет, по крайней мере, git так думает. Я бы попробовал git merge --abort, прежде чем переделывать твой git merge -s ours master
Вы пробовали использовать
rebaseвместо слияния? похоже, это больше подходит для вашей цели, посмотрите здесь: atlassian.com/git/tutorials/rewriting-history/git-rebase