Устранение конфликтов Git слияния в пользу их изменений во время вытягивания

Как разрешить конфликт слиянием git в пользу вытащинных изменений?

В основном мне нужно удалить все конфликтующие изменения из рабочего дерева без необходимости проходить через все конфликты с помощью git mergetool, сохраняя при этом все конфликтующие изменения. Предпочтительно делать это, пока вытягиваете, а не потом.

Ответы

Ответ 1

Вы можете использовать рекурсивную опцию "их" стратегии:

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.

Примечание. Как сказано в справочной странице, вариант "нашей" стратегии слияния сильно отличается от "своей" стратегии слияния.

Ответ 3

Если вы уже находитесь в конфликтующем состоянии и хотите просто принять их все:

git checkout --theirs .
git add .

Если вы хотите сделать обратное:

git checkout --ours .
git add .

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

Ответ 4

Итак, изобразите сценарий, в котором я был только что:

Вы пытаетесь выполнить 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

Удивительно, но я не мог найти этот ответ очень легко в Сети.

Ответ 5

Ответы git pull -X theirs могут создать уродливый коммит слияния или создать

ошибка: локальные изменения в следующих файлах будут перезаписаны слиянием:

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

git fetch && git reset --hard origin/master

Как это работает? git fetch выполняет git pull, но без слияния. Затем git reset --hard заставляет ваше рабочее дерево соответствовать последнему коммиту. Все ваши локальные изменения в файлах в репо будут отброшены, но новые локальные файлы будут оставлены в покое.

Ответ 6

Чтобы разрешить все конфликты с версией в конкретной ветке:

git diff --name-only --diff-filter=U | xargs git checkout ${branchName}

Итак, если вы уже находитесь в состоянии слияния и хотите сохранить основную версию конфликтующих файлов:

git diff --name-only --diff-filter=U | xargs git checkout master

Ответ 7

Пожалуйста, не то, что иногда это будет не работать:

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 не удаляет файлы из списка несвязанных файлов

Ответ 8

VS Code (интегрированный Git) IDE Пользователи:

Если вы хотите принять все входящие изменения в файле конфликта, выполните следующие действия.

1. Go to command palette - Ctrl + Shift + P
2. Select the option - Merge Conflict: Accept All Incoming

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

Ответ 10

После git merge, если у вас возникли конфликты, и вы хотите либо свой, либо их

git checkout --theirs .
git checkout --ours.

Ответ 11

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