Git merge конфликты в ретроспективе, понимание решений конфликтов

Question

На днях я провел здесь несколько часов, как мой коллега merge из master-branch в feature-branchмы работаем, и я помню, как за несколько дней до этого видел, что в двух файлах были конфликты. Я / мы используем smartgit и обычно во времяmergeпроцесс (насколько я помню) он пишет в сообщении фиксации, какие файлы конфликтуют с начальным знаком "#". Это означает, что лицо, имеющее дело с конфликтом, знает, какие файлы находятся в конфликте, и он будет с ним справляться, изменит сообщение фиксации и отправит изменения на сервер. Но люди послеmerge не знаю, какие файлы были в конфликте (потому что об этом позаботился тот, кто нажал кнопку merge-commit). Поскольку у нас были проблемы с компиляцией и ошибки в некоторых файлах, я попытался понять, было ли это связано с (а) неправильнымmerge-conflictобработка или (б) что-то еще. Я попытался найти решение, которое бы быстро и легко позволило мне увидеть:

1. Какие файлы конфликтовали во время merge?
2. Именно какой mergeconflict решения были приняты (для файлов из вопроса 1, как вы знаете, многие другие файлы также изменятся...)?
3. Основываясь на двух приведенных выше ответах, я бы сразу узнал во время компиляции, были ли проблемы сборки вызваны неправильным merge-conflict-обработка... Я просто хочу быстро "исключить" и знать, вызваны ли ошибки компиляции случайным неправильным merge-решение (а) или нет...

Когда много файлов merged, все просто усложняется (потому что многие файлы были / будут изменены одновременно). У меня есть "частичное решение" (это не "настоящее" решение), но я рассматриваю его как довольно долгий путь:

1. Я мог бы checkout фиксация, непосредственно перед merge.
2. Тогда попробуйте сделать mergeсебя. Это скажет мне о конфликтующих файлах.
3. Я мог бы записать эти имена файлов во временный файл (включая местоположение конфликтов, так что я могу отличить его от "неконфликтных" различий в тех же файлах!).
4. затем checkout Снова ГОЛОВА (где я был, отбросив лишнее "местное" merge с шага 2, так что я снова нахожусь merge-commit).
5. затем diff HEAD shaXX с фиксацией, непосредственно перед merge, только для тех конфликтующих имен файлов, которые я записал...
6. И тогда я бы понял, какое решение по разрешению конфликта было / было принято после mergeconflict разрешающая способность...

Но это много ручных шагов и ручной работы, не очень автоматизированной... Кроме того, этот метод подразумевает отображение различий между теми файлами, в которых есть конфликты, т.е. он покажет все различия, которые меня только интересуют при рассмотрении "merge-conflict решения по разрешению " - я могу рискнуть потратить свое время на просмотр сотен нерелевантных различий, то есть с этим методом мне все еще немного неясно, что merge-conflict решения были приняты (если я не очень тщательно записал это, когда я попытался выполнить слияние сам, опять же, после того, как оно было отправлено)... Поэтому мой вопрос: существует ли лучший (= более автоматизированный) метод и как?