Автоматическое слияние не является совершенным. Просто потому, что конфликт строк не изменяется, не означает, что не существует синтаксического конфликта, и это не означает, что не существует семантического конфликта.
Есть ли у кого-нибудь стратегии для разработки изменений с низким уровнем конфликтов? Это то, что выпадает из TDD или других подходов (Конечно, TDD поможет их поймать, но действительно ли это предотвратит)?
Классы, которые нарушают принцип единой ответственности}, сложнее всего слить. Поиск класса, который трудно было слить, вероятно, является признаком того, что его нужно реорганизовать, возможно, в сторону большего количества деталей.
Я всегда обнаружил, что чем меньше мои коммиты, тем меньше вероятность их слияния. Люди, у которых есть большие проблемы, всегда, кажется, уходят на несколько дней и работают над вещами, а затем пытаются объединить их все сразу.
Сейчас я работаю над командой из 2 человек, где мы все время правы в одной и той же кодовой базе. Каждый из нас работает в личной ветке, а затем интегрируется в общую ветвь, когда у нас что-то работает. Это обычно несколько раз в день. У нас почти нет конфликтов слияния, и когда мы делаем, они довольно тривиальны.
Итак... часто получайте последний код из репозитория. Работайте в своей собственной ветке, чтобы вы могли совершать свои изменения и объединять работу других людей, не затрагивая остальных членов команды. Затем нажимайте свой собственный код до общей ветки как можно чаще, чтобы изменения были как можно меньше.
Кроме того, поговорите с вашей командой. Если вы знаете, что кто-то другой работает в определенном файле, вам может потребоваться дождаться, когда они начнут работать, прежде чем вы перейдете. Иногда вы не можете помочь, но общение по крайней мере позволяет планировать сложное слияние, а не быть удивлен.
Прежде всего, ваша база кода должна быть модульной. Во-вторых, вам нужна связь с остальной частью вашей команды. Все должны знать, кто над этим работает. Если во внутреннем интерфейсе есть изменения, это должно быть понятным для всей команды.
Кроме того, перед выполнением команды всегда извлекайте последнюю версию, и если требуется сложное объединение, сделайте это локально.
Это действительно человеческая проблема, а не техническая. Контроль источника не заменяет надлежащие каналы связи. Ваш Менеджер проектов должен быть в числе всех изменений, и он должен понять, когда изменение будет охватывать несколько человек.
Кроме того, необходим общий смысл.:)
Тестирование модулей, конечно, является большой помощью для поиска наиболее неуловимых ошибок, которые могут возникнуть при слиянии.
Поговорите со своими коллегами-разработчиками и старайтесь избегать синхронного редактирования одного и того же блока кода, где это возможно. Наличие хорошо модульной архитектуры (небольшие классы, развязанные функциональные возможности) делает это возможным почти все время.
Если у нас когда-нибудь будет столкновение, мы часто разрешаем его одним из нас, переходим к написанию модульных тестов для непроверенного кода в течение нескольких минут.