Я считаю, что инструменты слияния редко помогают мне понять конфликт или решение. Я обычно более успешно смотрю на маркеры конфликта в текстовом редакторе и использую git log в качестве дополнения.
Вот несколько советов:
Совет первый
Лучшее, что я нашел, это использовать стиль конфликта слияния "diff3":
git config merge.conflictstyle diff3
Это приводит к появлению таких маркеров конфликта:
<<<<<<<
Changes made on the branch that is being merged into. In most cases,
this is the branch that I have currently checked out (i.e. HEAD).
|||||||
The common ancestor version.
=======
Changes made on the branch that is being merged in. This is often a
feature/topic branch.
>>>>>>>
Средняя часть - это то, на что был похож общий предок. Это полезно, потому что вы можете сравнить его с верхней и нижней версиями, чтобы лучше понять, что было изменено в каждой ветви, что дает вам лучшее представление о том, какова была цель каждого изменения.
Если конфликт состоит всего из нескольких строк, это обычно делает конфликт очень очевидным. (Знание того, как исправить конфликт, совсем другое; вам нужно знать, над чем работают другие люди. Если вы растерялись, лучше всего просто позвонить этому человеку в вашу комнату, чтобы он мог видеть, что вы ищете в.)
Если конфликт будет более продолжительным, я буду вырезать и вставлять каждый из трех разделов в три отдельных файла, таких как «мой», «общий» и «их».
Затем я могу запустить следующие команды, чтобы увидеть два различий, вызвавших конфликт:
diff common mine
diff common theirs
Это не то же самое, что использование инструмента слияния, поскольку инструмент слияния будет также включать все неконфликтующие блоки различий. Я нахожу это отвлекающим.
Совет второй
Кто-то уже упоминал об этом, но понимание намерений, стоящих за каждым другим источником, как правило, очень полезно для понимания того, откуда возник конфликт и как с ним справиться.
git log --merge -p <name of file>
Здесь показаны все коммиты, которые касались этого файла между общим предком и двумя головами, которые вы объединяете. (Таким образом, он не включает коммиты, которые уже существуют в обеих ветках до слияния.) Это помогает вам игнорировать блоки различий, которые явно не являются фактором в вашем текущем конфликте.
Совет три
Проверьте ваши изменения с помощью автоматизированных инструментов.
Если у вас есть автоматические тесты, запустите их. Если у вас есть lint , запустите его. Если это проект для сборки, то создайте его перед фиксацией и т. Д. Во всех случаях вам нужно провести небольшое тестирование, чтобы убедиться, что ваши изменения ничего не сломали. (Черт, даже слияние без конфликтов может нарушить рабочий код.)
Совет четвертый
Планируйте заранее; общаться с коллегами.
Планирование заблаговременно и знание того, над чем работают другие, может помочь предотвратить конфликты слиянием и / или помочь разрешить их раньше - хотя детали еще свежи в памяти.
Например, если вы знаете, что вы и другой человек работаете над различным рефакторингом, который будет влиять на один и тот же набор файлов, вам следует заранее поговорить друг с другом и лучше понять, какие типы изменений каждый из вас делает. Вы можете сэкономить много времени и усилий, если планируете вносить изменения последовательно, а не параллельно.
Для крупных рефакторингов, которые затрагивают большую часть кода, вам следует настоятельно рекомендовать работать последовательно: все прекращают работать над этой областью кода, пока один человек выполняет полный рефакторинг.
Если вы не можете работать последовательно (возможно, из-за нехватки времени), то сообщение об ожидаемых конфликтах слияния по крайней мере поможет вам быстрее решить проблемы, пока детали еще свежи. Например, если сотрудник совершает серию разрушительных коммитов в течение однонедельного периода, вы можете выбрать слияние / перебазирование в этом филиале коллег один или два раза в день в течение этой недели. Таким образом, если вы обнаружите конфликты слияния / перебазирования, вы сможете разрешить их быстрее, чем если бы вы подождали несколько недель, чтобы объединить все в один большой кусок.
Совет пятый
Если вы не уверены в слиянии, не форсируйте его.
Слияние может показаться ошеломляющим, особенно когда существует много конфликтующих файлов, а маркеры конфликта занимают сотни строк. Часто при оценке программных проектов мы не учитываем достаточно времени для таких накладных расходов, как обработка грубого слияния, поэтому кажется, что это настоящая трата - потратить несколько часов на анализ каждого конфликта.
В долгосрочной перспективе планирование заранее и понимание того, над чем работают другие, являются лучшими инструментами для предвидения конфликтов слияний и подготовки к их правильному разрешению за меньшее время.