Как разрешить конфликт слиянием git в пользу вытащинных изменений?
В основном мне нужно удалить все конфликтующие изменения из рабочего дерева без необходимости проходить через все конфликты с помощью git mergetool, сохраняя при этом все конфликтующие изменения. Предпочтительно делать это, пока вытягиваете, а не потом.
Вы можете использовать рекурсивную опцию "их" стратегии:
git merge --strategy-option theirs
От человека:
ours
This option forces conflicting hunks to be auto-resolved cleanly by
favoring our version. Changes from the other tree that do not
conflict with our side are reflected to the merge result.
This should not be confused with the ours merge strategy, which does
not even look at what the other tree contains at all. It discards
everything the other tree did, declaring our history contains all that
happened in it.
theirs
This is opposite of ours.
Примечание. Как сказано в справочной странице, вариант "нашей" стратегии слияния сильно отличается от "своей" стратегии слияния.
git pull -s recursive -X theirs <remoterepo or other repo>
Или, просто, для репозитория по умолчанию:
git pull -X theirs
Если вы уже находитесь в конфликтном состоянии...
git checkout --theirs path/to/file
Если вы уже находитесь в конфликтующем состоянии и хотите просто принять их все:
git checkout --theirs .
git add .
Если вы хотите сделать обратное:
git checkout --ours .
git add .
Это довольно сильно, поэтому убедитесь, что вы действительно хотите стереть все, как это, прежде чем делать это.
Итак, изобразите сценарий, в котором я был только что:
Вы пытаетесь выполнить merge или, возможно, cherry-pick, и вы остановились на
$ git cherry-pick 1023e24
error: could not apply 1023e24... [Commit Message]
hint: after resolving the conflicts, mark the corrected paths
hint: with 'git add <paths>' or 'git rm <paths>'
hint: and commit the result with 'git commit'
Теперь вы просматриваете конфликтный файл, и вы действительно не хотите сохранять свои изменения. В моем случае выше файл был конфликтует только с новой линией, которую моя IDE автоматически добавила. Чтобы отменить изменения и принять их, самый простой способ:
git checkout --theirs path/to/the/conflicted_file.php
git add path/to/the/conflicted_file.php
Обратное это (для перезаписывания входящей версии вашей версии)
git checkout --ours path/to/the/conflicted_file.php
git add path/to/the/conflicted_file.php
Удивительно, но я не мог найти этот ответ очень легко в Сети.
Ответы git pull -X theirs могут создать уродливый коммит слияния или создать
ошибка: локальные изменения в следующих файлах будут перезаписаны слиянием:
Если вы хотите просто игнорировать любые локальные изменения в файлах из репозитория, например, на клиенте, который всегда должен быть зеркалом источника, запустите это (замените master на нужную вам ветку):
git fetch && git reset --hard origin/master
Как это работает? git fetch выполняет git pull, но без слияния. Затем git reset --hard заставляет ваше рабочее дерево соответствовать последнему коммиту. Все ваши локальные изменения в файлах в репо будут отброшены, но новые локальные файлы будут оставлены в покое.
Чтобы разрешить все конфликты с версией в конкретной ветке:
git diff --name-only --diff-filter=U | xargs git checkout ${branchName}
Итак, если вы уже находитесь в состоянии слияния и хотите сохранить основную версию конфликтующих файлов:
git diff --name-only --diff-filter=U | xargs git checkout master
Пожалуйста, не то, что иногда это будет не работать:
git checkout --ours path/to/file
или
git checkout - их путь/в/файл
Я сделал это вместо этого, предполагая, что HEAD - наш и MERGE_HEAD - это
git checkout HEAD -- path/to/file
или
git checkout MERGE_HEAD -- path/to/file
После этого мы добьемся:
git add .
Если вы хотите понять больше, см. замечательный пост torek: git checkout --ours не удаляет файлы из списка несвязанных файлов
VS Code (интегрированный Git) IDE Пользователи:
Если вы хотите принять все входящие изменения в файле конфликта, выполните следующие действия.
1. Go to command palette - Ctrl + Shift + P
2. Select the option - Merge Conflict: Accept All Incoming
Точно так же вы можете использовать другие параметры, такие как Принять все оба, Принять все текущие и т.д.,
Для репозитория по умолчанию это так же просто, как:
git pull -X theirs
Если вы уже находитесь в конфликтующем состоянии это немного отличается от другого, но все же управляемо.
После git merge, если у вас возникли конфликты, и вы хотите либо свой, либо их
git checkout --theirs .
git checkout --ours.
from https://git-scm.com/book/en/v2/Git-Tools-Advanced-Merging
В основном это будет поддельное слияние. Он будет записывать новое слияние с обеих ветвей в качестве родителей, но он даже не будет смотреть на ветку вы объединяетесь. Он просто записывается в результате слияния точный код в вашей текущей ветке.
$ git merge -s ours mundoСлияние, созданное стратегией "наш".
$ git diff HEAD HEAD~Вы можете видеть, что нет разницы между веткой, на которой мы были и результат слияния.
Это часто может оказаться полезным для трюка Git, считая, что ветвь уже слита при слиянии позже. Например, скажем вы отделили отделение релиза и проделали над ним некоторую работу, вы захотите в какой-то момент снова объединиться в свою основную ветку. В тем не менее, некоторые исправления для мастера должны быть отправлены обратно в ваш релиз. Вы можете объединить ветку bugfix в выпуск ветвь, а также объединить нашу ветку в вашу основную ветвь (хотя исправление уже существует), поэтому, когда вы позже объедините релиз, снова нет конфликтов с исправлением.
Ситуация, которую я нашел полезной, если я хочу, чтобы мастер отражал изменения в новой ветке темы. Я заметил, что в некоторых случаях они не сливаются без конфликтов... например.
$ git merge -Xtheirs topicFoo
CONFLICT (modify/delete): js/search.js deleted in HEAD and modified in topicFoo. Version topicFoo of js/search.js left in tree.
В этом случае решение, которое я нашел, было
$ git checkout topicFoo
из topicFoo, сначала слияние в master с помощью стратегии -s ours, это создаст фальшивую фиксацию, которая является только состоянием topicFoo. $ Git merge -s ours master
проверить созданный слияние
$ git log
теперь проверить мастер-ветку
$ git checkout master
объединить ветку темы, но на этот раз использовать рекурсивную стратегию -Xtheirs, теперь она представит вам ведущую ветвь с состоянием topicFoo.
$ git merge -X theirs topicFoo