Я провел здесь несколько часов на днях, когда коллега сделал merge из master-branch в feature-branch, над которым мы работаем, и я помню, как видел несколько дней назад, что Были конфликты в 2 файлах. Я / мы используем smart git и, как правило, во время процесса merge (насколько я помню) в сообщении фиксации записывается, какие файлы конфликтуют с лидирующей "#" в начале. Это означает, что человек, имеющий дело с конфликтом, знает, какие файлы находятся в конфликте, и он с этим справится, изменит сообщение коммита и отправит изменения на сервер. Но люди после merge не знают, какие файлы конфликтовали (потому что об этом позаботился тот, кто нажал merge-commit). Поскольку у нас были проблемы с компиляцией и обнаружены ошибки в некоторых файлах, я попытался понять, было ли это из-за (а) неправильной обработки merge-conflict или (б) чего-то другого. Я пытался найти решение, которое бы быстро и легко позволило мне увидеть:
- Какие файлы находились в конфликте во время
merge? - Какое именно решение
merge conflict было взято (для файлов из вопроса 1, как вы знаете, многие другие файлы также изменятся ...)? - Исходя из 2 приведенных выше ответов, я бы сразу узнал во время компиляции, были ли проблемы со сборкой вызваны некорректно
merge-conflict -обработка ... Я просто хочу быстро "исключить" и узнать, вызваны ли ошибки компиляции случайно неверными merge -решениями или нет ...
Когда много файлов merged, все просто усложняется (потому что многие файлы имеют / будут изменены сразу). У меня есть «частичное решение» здесь (это не «реальное» решение), но я вижу его как довольно долгий путь:
- Я мог бы
checkout коммит, как раз перед merge. - Тогда попробуй сделать
merge сам. Это сообщит мне конфликтующие файлы. - Я мог бы записать эти имена файлов во временный файл (включая расположение конфликтов тоже, чтобы я мог отличить guish его от "неконфликтующих" различий) в тех же самых файлах!).
- Затем
checkout HEAD снова (где я был, отбрасывая лишние "локальные" merge из шага 2, так что я вернулся к нажатому merge -коммиту ). - Затем
diff HEAD shaXX с коммитом, перед merge, для только тех конфликтующих имен файлов, которые я записал ... - И тогда я бы понял, какое решение по урегулированию конфликта было / было принято после
merge conflict разрешения ...
Но это много ручных шагов и ручной работы, не очень автоматизированных ... Также Этот метод подразумевает отображение различий между файлами, в которых есть конфликты, т.е. он показывает все различий, где меня интересует только просмотр "merge-conflict решений о разрешении" - я могу рисковать тратить свое время, глядя на сотни несущественных диф fs, имея ввиду этот метод, мне все еще немного неясно, какие merge-conflict решения были приняты (если только я не очень тщательно это записал, когда попытался выполнить слияние самостоятельно, после того, как оно было передано) .. Поэтому мой вопрос: существует ли лучший (= более автоматизированный) метод и как?