Самый опасный merge часто проходит без конфликтов.

Git видит, что ветки меняли разные строки. Проект собирается, тесты зелёные. Но реализации всё равно могут по-разному отвечать на архитектурные вопросы:

• какая модель является основной; • кто владеет состоянием; • где проходит граница модуля; • какой контракт должен сохраниться; • что происходит при ошибке или повторе; • расширяет ли новая логика существующую систему или создаёт параллельную.

Git обнаруживает текстовые конфликты. Семантические могут пережить merge, сборку и текущий набор тестов.

Если ветки разошлись архитектурно, безопаснее не переносить одну из них целиком, а:

• выбрать authoritative model; • инвентаризировать полезные возможности второй реализации; • переносить их небольшими законченными частями; • проверить contracts, migrations и failure paths; • запустить систему с чистого состояния; • пройти критический сценарий end-to-end; • зафиксировать, что сознательно не переносилось.

Зелёные тесты подтверждают только те ожидания, которые были в них заложены. Они не доказывают, что после объединения получилась одна архитектура.

Git отвечает, можно ли соединить изменения в одном дереве файлов. Инженер отвечает, получилась ли после этого одна понятная система.

Чистый merge — технический факт. Совместимая архитектура — инженерное доказательство.