Я использовал git pull и имел конфликт слияния:
unmerged: _widget.html.erb
You are in the middle of a conflicted merge.
Я знаю, что другая версия файла хороша и моя шахматная, поэтому все мои изменения должны быть отменены. Как я могу это сделать?
Поскольку ваш pull был неудачным, тогда HEAD (not HEAD^) является последним "действительным" фиксацией в вашей ветке:
git reset --hard HEAD
Другая часть, которую вы хотите, должна позволить своим изменениям превышать ваши изменения.
Старые версии git позволили вам использовать стратегию слияния "их":
git pull --strategy=theirs remote_branch
Но это с тех пор было удалено, как описано в это сообщение Юнио Хамано (сопровождающий git). Как указано в ссылка, вместо этого вы сделаете следующее:
git fetch origin
git reset --hard origin
Если ваша версия git равнa > 1.6.1, вы можете использовать git reset --merge.
Кроме того, как упоминает @Michael Johnson, если ваша версия git равнa > 1.7.4, вы также можете использовать git merge --abort.
Как всегда, перед запуском слияния убедитесь, что у вас нет незафиксированных изменений.
На странице git merge man
git merge --abort эквивалентен git reset --merge, когда присутствует MERGE_HEAD.
MERGE_HEAD присутствует, когда выполняется слияние.
Кроме того, в отношении незафиксированных изменений при запуске слияния:
Если у вас есть изменения, которые вы не хотите совершать до начала слияния, просто git stash их перед слиянием и git stash pop после завершения слияния или отмены его.
git merge --abort
Прервать текущий процесс разрешения конфликтов и попытаться восстановить состояние предварительного объединения.
Если были неработающие изменения рабочей ситуации, присутствующие при слиянии началось,
git merge --abortв некоторых случаях не сможет восстановите эти изменения. Поэтому рекомендуется всегда зафиксируйте или запишите свои изменения перед запуском git merge.
git merge --abortэквивалентноgit reset --merge, когдаMERGE_HEAD.
Это так просто.
git merge --abort
Git сам покажет вам решение, когда вы находитесь в такой ситуации, и запустите команду git status.
git status
Надеюсь, это поможет людям.
Я думаю, что вам нужно git reset.
Остерегайтесь того, что git revert означает что-то очень отличное от, скажем, svn revert - в Subversion возврат будет отбрасывать ваши (незафиксированные) изменения, возвращая файл в текущую версию из репозитория, тогда как git revert "отменяет" фиксация.
git reset должен делать эквивалент svn revert, то есть отбрасывать нежелательные изменения.
В этом конкретном случае использования вы действительно не хотите прервать слияние, просто разрешите конфликт определенным образом.
Нет особой необходимости в reset и выполнять слияние с другой стратегией. Конфликты были правильно выделены с помощью git, и требование принять изменения сторонних сторон - только для этого одного файла.
Для несвязанного файла в конфликте git предоставляет доступную общую базу, локальную и удаленную версии файла в индексе. (Здесь они считываются для использования в трехстороннем инструменте diff с помощью git mergetool.) Вы можете использовать git show для их просмотра.
# common base:
git show :1:_widget.html.erb
# 'ours'
git show :2:_widget.html.erb
# 'theirs'
git show :3:_widget.html.erb
Самый простой способ разрешить конфликт для использования удаленной версии дословно:
git show :3:_widget.html.erb >_widget.html.erb
git add _widget.html.erb
Или, с git >= 1.6.1:
git checkout --theirs _widget.html.erb
Поскольку комментарии предполагают, что git reset --merge является псевдонимом для git merge --abort, стоит заметить, что git merge --abort эквивалентен только git reset --merge, если присутствует a MERGE_HEAD. Это можно прочитать в справке git для команды merge.
git merge --abort is equivalent to git reset --merge when MERGE_HEAD is present.
После неудачного слияния, когда нет MERGE_HEAD, сбойное слияние может быть отменено с помощью git reset --merge, но необязательно с git merge --abort, , поэтому они не только старый и новый синтаксис для одной и той же вещи.
Лично я нахожу git reset --merge гораздо более мощным для сценариев, подобных описанному, и неудачных слияний вообще.
И если вы закончите конфликт слиянием и не имеете каких-либо вещей для фиксации, но все же ошибка слияния отображается после применения всех указанных ниже команд,
git reset --hard HEAD
git pull --strategy=theirs remote_branch
git fetch origin
git reset --hard origin
удалите
.git\index.lock
файл [вырезать пасту в другое место в случае восстановления], а затем ввести любую из нижеуказанных команд в зависимости от того, какую версию вы хотите.
git reset --hard HEAD
git reset --hard origin
Надеюсь, это поможет!!!
Так как Git 1.6.1.3 git checkout удалось проверить с обеих сторон слияния:
git checkout --theirs _widget.html.erb
Альтернативой, сохраняющей состояние рабочей копии, является:
git stash
git merge --abort
git stash pop
Я вообще советую против этого, потому что это эффективно, как слияние в Subversion, поскольку оно отбрасывает отношения ветвления в следующем commit.
Для такого сценария я сделал git fetch и git pull, а затем понял, что восходящая ветвь не была главной ветвью, что приводило к нежелательным конфликтам.
git reset --merge
Это вернулось назад без сброса локальных изменений.
Я нашел, что для меня работало (верните один файл в состояние предварительного объединения):
git reset *currentBranchIntoWhichYouMerged* -- *fileToBeReset*