Как я могу создавать изменения, которые не подвержены конфликтам слияний? - PullRequest
3 голосов
/ 07 августа 2009

Автоматическое объединение не идеально. Тот факт, что нет конфликта редактирования строки, не означает, что нет синтаксического конфликта, и это не означает, что нет семантического конфликта.

Есть ли у кого-нибудь стратегии для авторизации изменений с низким уровнем конфликта? Это что-то, что выпадает из TDD или других подходов (конечно, TDD поможет их поймать, но действительно ли это предотвращает)?

Ответы [ 4 ]

4 голосов
/ 07 августа 2009

Я всегда обнаруживал, что чем меньше мои коммиты, тем меньше вероятность возникновения конфликтов слияния. Люди, у которых большие проблемы, кажется, уходят на несколько дней и работают над вещами, а затем пытаются объединить их всех сразу.

Сейчас я работаю в команде из 2 человек, где мы постоянно находимся в одной и той же кодовой базе. Каждый из нас работает в личной ветке, а затем интегрируется в общую ветку, когда у нас что-то работает. Это обычно несколько раз в день. У нас почти никогда не бывает конфликтов слияния, и когда мы это делаем, они довольно тривиальны.

Итак ... часто получайте последний код из репозитория. Работайте в своей собственной ветке, чтобы вы могли зафиксировать свои изменения и объединить работу других людей, не затрагивая остальную часть команды. Затем отправляйте свой собственный код в общую ветку как можно чаще, чтобы изменения были как можно меньше.

Кроме того, поговорите со своей командой. Если вы знаете, что кто-то еще работает с определенным файлом, вы можете подождать, пока они не приступят к работе, прежде чем вы подключитесь. Иногда вы не можете ничего с этим поделать, но общение по крайней мере позволяет планировать сложное слияние, а не удивлен.

2 голосов
/ 07 августа 2009

Прежде всего, ваша кодовая база должна быть модульной. Во-вторых, вам нужно общение с остальными членами вашей команды. Все должны знать, кто над чем работает. Если во внутреннем API есть изменение, это должно быть ясно для всей команды.

Кроме того, перед фиксацией всегда выбирайте последнюю версию, а если необходимо сложное объединение, делайте это локально.

Это действительно человеческая проблема, а не техническая. Контроль источника не заменяет надлежащие каналы связи . Ваш менеджер проекта должен быть в курсе всех изменений, и он должен понимать, когда изменение охватит несколько человек.

Кроме того, необходим здравый смысл. :)

Юнит-тестирование, конечно, очень помогает выявлять самые неуловимые ошибки, которые могут возникнуть при слиянии.

1 голос
/ 07 августа 2009

Поговорите со своими коллегами-разработчиками и постарайтесь избегать синхронного редактирования одного и того же блока кода, где это возможно. Хорошо модульная архитектура (небольшие классы, разделенная функциональность) делает это возможным почти всегда.

Если у нас когда-либо возникает конфликт, мы часто разрешаем его, когда один из нас переключается на написание модульных тестов для непроверенного кода на несколько минут.

...