git снова слить после слияния и фиксации?

Question

Чтобы вручную объединить запрос на перенос, я выполнил инструкции github:
Шаг 1. Из репозитория проекта внесите изменения и протестируйте.
git fetch origin
git checkout -b featureBranch origin/featureBranch
git merge develop
Это привело к 3 конфликтам. Я запустил git mergetool <filename> для всех трех файлов и разрешил конфликты. Без проблем. Без дальнейших конфликтов я зафиксировал изменения. Я еще не пу sh. Коллега заметил, что я неправильно слил один файл. Из-за большого количества времени, которое потребовалось для объединения конфликтов, я бы предпочел объединить разработку с только что объединенным файлом вместо сброса и повторного выполнения всего слияния.
Однако, когда я запускаю git mergetool develop <file> git bash возвращает No files need merging, что также ожидается, но не то, что я хочу.
git diff develop <file> показывает, что есть различия, которые тоже ожидаются.
Можно ли повторно объединить разработку в мою ветку функций?

Answer 1

Команда git mergetool зависит от наличия конфликтного состояния. Разрешение файла удаляет конфликтное состояние, благодаря чему git mergetool узнает, что файл теперь объединен. Это позволяет вам объединить некоторые файлы, полностью выйти из mergetool, снова запустить mergetool и продолжить с того места, где вы остановились. Но это означает, что когда вы разрешаете git mergetool помечать файл как «разрешенный», это все для этого файла.

Если вы не завершили и не зафиксировали слияние, т. Е. Еще не запустили git merge --continue или git commit - можно восстановить файл до состояния без объединения. ¹ Здесь есть большое предостережение - это стирает всю работу, которую вы проделали по слиянию до сих пор (поэтому сохраните файл сначала в другом месте! ) - и, конечно, в любом случае не применяется в вашем случае, потому что вы выполнили sh слияние.

Это означает, что вы не можете использовать git mergetool, чтобы исправить проблему - по крайней мере, без повторения слияния.

У вас есть несколько вариантов, потому что Git - это набор инструментов, а не решение. Вот два:

1. Сохраните результат слияния. Что ж, вы делаете это автоматически: это коммит . Сохраните где-нибудь commit ha sh ID , обычно создавая имя ветки или тега, чтобы запомнить его. Вы можете записать это на бумаге, но скопировать ID ha sh вручную слишком сложно. Вы можете сохранить его в файл ... но это то, что делают git tag и git branch, так почему бы не использовать один из них?

   git tag saved-result
   

   Затем сотрите слияние с помощью git reset --hard вернуться в состояние до слияния. Повторно запустите слияние. Используйте сохраненный коммит , чтобы получить правильно слитые файлы:

   git reset --hard HEAD~1
   git merge otherbranch
   
   git checkout saved-result -- file1.ext file2.ext
   

   Эти два файла теперь помечены как разрешенные и готовы к go новой сделанной вами фиксации слияния.

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

   git show saved-result:file3.ext > file3.ext.previous-merge-attempt
   

   Теперь запустите git mergetool или что угодно, чтобы поработать с file3.

   Когда все будет готово, удалите использованное имя ветви или тега:

   git tag -d saved-result
   

   , например.

2. Использование результата слияния у вас есть теперь, откройте неправильно объединенный файл. Найдите неверно объединенный результат и измените его. Если вы хотите просмотреть два или три входных параметра ранее, вы можете получить их:

   git show HEAD^1:file3.ext > file3.ext.ours
   git show HEAD^2:file3.ext > file3.ext.theirs
   

   Получить базовую версию слияния file3.ext немного сложнее:

   git merge-base --all HEAD^1 HEAD^2
   

   Это должно распечатать один га sh ID. Если он печатает более одного, у вас было рекурсивное слияние . Предполагая, что вы этого не сделали, вырежьте и вставьте только что напечатанный идентификатор ha sh:

   git show <hash>:file3.ext > file3.ext.base
   

   Теперь у вас есть все три входных файла - те, которые видел бы ваш инструмент слияния, но не Git попытка слияния. Если вы хотите получить Git, чтобы показать вам, что он вводит для конфликтов, используйте git merge-file как это:

   cp file3.ext.ours file3.ext.conflicted
   git merge-file file3.ext.conflicted file3.ext.base file3.ext.theirs
   

   Теперь у вас есть все четыре файла. Откройте файл (ы) в любом просмотре (ах) и / или редакторе (ах), который вам нравится, исправьте версию file.ext и запишите ее, а затем замените существующую фиксацию слияния новой фиксацией слияния, сделанной с использованием обновленного file:

   git add file3.ext
   git commit --amend
   

   (Существующая фиксация слияния продолжает существовать в вашем репозитории и по умолчанию будет находиться там не менее 30 дней, но вы не увидите , если только вы go ищет в журналах.)

---

¹ Здесь это бесполезно, но мы могли бы также сказать, как это сделать: используйте git checkout -m в файле, например, git checkout -m -- path/to/file.ext. Это стирает запись с нулевым слотом и возвращает записи слот-1, слот-2 и слот-3 в индекс Git, а также воссоздает конфликты слияния в копии рабочего дерева файла.

Обратите внимание, что git checkout -m при фиксации , когда не в середине конфликтного слияния, делает что-то совершенно другое!