У нас очень похожий рабочий процесс, но есть несколько ключевых шагов, которые разработчики должны выполнить, чтобы избежать большинства проблем слияния.Основное отличие вашего рабочего процесса заключается в том, что каждый из наших разработчиков имеет долгоживущую ветвь разработки, которая похожа на ваши ветки дел.После объединения исправления / функции из ветви разработки с веткой выпуска разработчик может продолжить использовать свою ветку разработки для работы над следующим исправлением / функцией.Таким образом, наш рабочий процесс выглядит следующим образом:
Примечание: $ SVN_REPOS - это переменная среды, содержащая URL-адрес нашего хранилища Subversion.
Создана новая ветвь разработки дляразработчик из HEAD ветки релиза:
svn copy $SVN_REPOS/branches/release_branch $SVN_REPOS/branches/development_branch
Разработчик проверяет свою ветку разработки и внедряет их исправления / функции в рабочей области ветки разработки - предпочтительно часто фиксируя в хранилище.
Прежде чем реинтегрировать свои изменения в ветке разработки в ветку релиза, они должны объединить все новые изменения, сделанные в ветке релиза, с веткой разработки.На этом этапе разработчик интегрирует свои изменения с работой, выполненной с момента создания их ветви разработки.Для этого у нас есть пара правил:
- Для объединения из ветки релиза используется чистая рабочая область development_branch, т.е. все изменения исправлений / функций были зафиксированы.Наличие чистой рабочей области позволяет избежать любого конфликта слияния с незафиксированным кодом.
- Слияние из ветви выпуска происходит в корне дерева каталогов рабочей области.Это позволяет избежать рабочей области со смешанными ревизиями и гарантирует, что свойство Subversion svn: mergeinfo записывается в верхней части дерева кода ветки разработки.
- Разработчики обучены понимать, что они интегрируют код других людей на этом этапе,и поэтому они должны тщательно рассмотреть разрешение конфликта.Это лучшая страна для потери изменений других разработчиков, если разрешение конфликтов решается по-быстрому.Хорошая вики-страница, описывающая шаги по разрешению конфликтов и типичные сценарии, также является хорошей идеей.
- Изменения, объединенные из ветки релиза, фиксируются без внесения каких-либо других исправлений / изменений функций.Это гарантирует, что мы получим один ревизионный коммит, содержащий только изменения, слитые из ветки релиза, у нас также есть стандартный комментарий коммита, который должен использоваться для этого коммита - «Обновление ветки разработчика из release_branch».Эта единственная фиксация «только слияние изменений» также позволяет легко отменить слияние, если что-то пойдет не так, без потери каких-либо функциональных изменений.
Сделав свои функциональные изменения и обновив ветку разработки, разработчик теперь просит объединить их изменения с веткой выпуска.У нас есть конкретный человек, который следит за веткой релиза и выполняет все слияния из веток разработки.Они извлекут свежую копию ветки релиза и выполнят слияние реинтеграции из ветки разработки в рабочую область ветки релиза.Как и во всех наших слияниях, это происходит в корне дерева кода.Любые конфликты отправляются обратно разработчику, без каких-либо обязательств в ветке релиза.Разработчик должен будет обновить свою ветку разработки из ветки релиза и разрешить конфликты, прежде чем запрашивать другое слияние с веткой релиза. Примечание: Команда svn merge --reintegrate сообщит об ошибке до начала слияния, если ветвь разработки "устарела".
Номер редакции коммита ветки выпуска отмечен, и«блокирующее» слияние добавляется в ветку разработки.Предположим, что в этом примере мы добавили изменения development_branch в ветку релиза в редакции 112. В рабочей области для ветки разработки:
svn merge --record-only -c 112 $SVN_REPOS/branches/release_branch
svn commit --depth=immediates . -m "Block development_branch to release_branch merge revision 112 from being merged back into rel_05_01_001"
Это ключ к долгосрочному развитию отрасли.Когда в следующий раз разработчик обновит свою ветку разработки новыми изменениями в ветке релиза, слияние не повлечет за собой версию 112, которая содержит изменения, уже внесенные в ветку разработки.Это позволяет избежать целого ряда конфликтов.По сути, слияние --record-only заставляет Subversion думать, что ревизия 112 еще не была объединена с веткой разработки, хотя на самом деле это всего лишь маркер, а файлы не были объединены.
Таким образом, мы в основном избегаемпроблемы слияния, потому что мы всегда сливаемся в «чистые» рабочие области и последовательно сливаемся в верхней части дерева кода.Трюк --record-only удобен, так как мы предпочитаем избегать дополнительных затрат на создание отдельной ветки для каждого исправления / функции.Вот хорошая статья о том, как Subversion отслеживает слияния с помощью свойства Subversion mergeinfo: