Как узнать, какие коммиты Git вызывают конфликты?

Я объединяю исходные изменения в свой проект, и недавно было много коммитов, которые создали много конфликтов слияния. Не имеет смысла пытаться решить их все сразу.

Как я могу узнать, какие коммиты создают конфликт? Любое из следующего является приемлемым:

  • Способ заставить Git прекратить слияние, как только обнаружит конфликт
  • Способ заставить Git перечислить все конфликтующие коммиты в хронологическом порядке.
  • Что-нибудь еще, что позволяет мне разрешать конфликты один за другим, в хронологическом порядке, что не включает в себя слияние нескольких коммитов за раз в надежде наткнуться на конфликты

person Davis Sorenson    schedule 10.08.2013    source источник
comment
Git немного отличается от svn. Он пытается объединить все коммиты сразу. Вы можете попробовать интерактивную перезагрузку, которая применяет коммиты одну за другой и дает сбой, как только обнаруживается конфликт.   -  person madhead    schedule 10.08.2013


Ответы (3)


Вы можете попробовать git imerge: это применит ваши коммиты на один, что дает вам возможность выполнить перебазирование поэтапно (это означает, что вы можете начать перебазирование, прервать его, возобновить позже!).

Здесь вы можете увидеть сравнение между инкрементным слиянием и добавочным слиянием. прямое слияние или перебазирование.

person VonC    schedule 10.08.2013
comment
git imerge определенно полезен. - person John Szakmeister; 10.08.2013
comment
Спасибо! Это тоже хорошее решение, но git-mergemate по умолчанию делает именно то, что я имел в виду. git-imerge также хорош, но немного излишен для моих нужд. - person Davis Sorenson; 10.08.2013
comment
Вместо использования внешнего инструмента, такого как git imerge, вы также можете просто попробовать отбор вишен из ряда ревизий, чтобы увидеть, какие из них конфликтуют, по одной за раз (в основном это похоже на rebase). - person ; 10.08.2013

У Майкла Хаггерти также есть инструмент под названием git-mergemate с командой find-conflict:

git-mergemate find-conflict BRANCH1..BRANCH2

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

git-mergemate find-conflict BRANCH1...BRANCH2

Используйте деление пополам, чтобы найти пару самых ранних коммитов (по одному из каждой ветки), которые не сливаются полностью. На самом деле не сохраняйте никаких слияний.

git imerge можно использовать для поэтапного слияния и разрешения конфликтов, хотя он не имеет эквивалент find-conflicts в git-mergemate.

person John Szakmeister    schedule 10.08.2013
comment
По ссылке кажется, что git-mergemate на самом деле просто старая версия git imerge, предложенная в ответе VonC ниже. Вероятно, вам следует отредактировать этот ответ, чтобы он указывал непосредственно на imerge. - person Mark Amery; 04.02.2014

Есть ли причина, по которой вы не хотите использовать rebase (неинтерактивно) для синхронизации с изменениями в восходящей ветке? Он остановится, если возникнет конфликт при каждом коммите, а затем вы сможете возобновить перебазирование, когда он будет разрешен. Это похоже на инкрементное слияние, и оно встроено прямо в Git, нет необходимости во внешнем плагине/инструменте:

git fetch <remote>
git rebase <remote>/<upstream-branch>
# Conflict on commit X, resolve conflict, then continue the rebase
git rebase --continue

Предупреждение о принудительном нажатии переписанных коммитов

Обратите внимание, конечно, что перебазирование вашей локальной ветки изменит идентификаторы sha ее коммитов. Если вы уже отправили коммиты, которые хотите перебазировать, на свой пульт, вам нужно будет принудительно отправить новые коммиты, чтобы перезаписать старые, что может создать потенциальную проблему, если вы делитесь своей веткой с другими людьми. . Вы можете узнать больше об этих проблемах в:

person Community    schedule 10.08.2013
comment
Rebase — это хорошо, но вы часто не захотите перебазировать в ветку, уже отправленную вверх по течению (также может быть недоступна принудительная фиксация) - person ideasman42; 06.08.2014
comment
@ ideasman42 Я не понимаю, что вы подразумеваете под принудительной фиксацией. Что это должно быть? В Git нет такой команды или параметра. Вы имеете в виду силу push? - person ; 06.08.2014
comment
извините, я имел в виду force-push - person ideasman42; 06.08.2014
comment
@ideasman42 также, исходный постер пытается объединить исходные изменения в свою локальную ветку. Мой ответ не перебазирует восходящий поток, он перебазирует неотправленную локальную ветку поверх восходящего потока. Нет необходимости принудительно нажимать мой ответ, потому что он не перебазирует отправленные коммиты. - person ; 06.08.2014
comment
@ideasman42 Я неправильно понимаю твой первый комментарий? Что значит перебазировать в ветку? В вопросе также нет ничего, что говорило бы о том, что первоначальный постер уже внес свои локальные изменения в удаленное репо. - person ; 06.08.2014
comment
@ ideasman42 Я не думаю, что мне действительно было необходимо что-то говорить о перемещении выдвинутых веток, поскольку исходный плакат никогда ничего не говорил о том, что он уже отправил свою локальную ветку на удаленную, только о том, что он пытается слиться с изменениями восходящего потока. Тем не менее, я пошел дальше и добавил короткую заметку о потенциальных проблемах, связанных с перемещением отправленных коммитов. - person ; 06.08.2014
comment
Это не помогает идентифицировать фиксацию в ветке, на которую вы перемещаете на и которая вызвала конфликт, а только на той ветке, которую вы перемещаете. - person naught101; 21.04.2019