1. Управление версиями для
нескольких команд в
корпоративных проектах
Автор: Дубовецкий Руслан
Харьков 2014 Artezio

2. Проблемы
• Конфликты при «коммите»
• Затирание чужих изменений
• Остановка корректной работы команды при нерабочем коде в
ветках
• Проблема согласования версий модулей и компонентов в ветках
• Сложная структура веток
• Ненужные ветки
• Дублирование веток
Харьков 2014 Artezio

3. Цель
• Быстрое информирование об ошибках
• Конфликты кода и проблемы интеграции должны обнаруживаться как
можно раньше.
• Лучше исправлять небольшие ошибки часто, чем большие проблемы
редко.
• Постоянная готовность к поставке
• Даже после действительно плохой итерации должно быть хоть что-то, что
можно выпустить.
• Простота
• Все члены команды будут ежедневно использовать эту схему, поэтому
правила должны быть простыми и понятными.
Харьков 2014 Artezio

4. Концепция шаблона управления
версиями
Для эффективного управления версиями ПО, стоит разделить
проект на ветки по командам(есть еще по модулям):
• Главная ветка Trunk(код всегда готов к релизу).
• Рабочие ветки команд.
• Ветки релизов.
Харьков 2014 Artezio
// Правило: Каждая ветвь (даже основной ствол, т.е. trunk)
имеет владельца и политику

5. Главная ветка Trunk
Готово к поставке - означает, что интеграционные,
модульные тесты пройдены и код не блокирует,
уже работающую, функциональность
Харьков 2014 Artezio
// Правило: Не совмещайте несколько циклов разработки в одной ветве

6. Публикация из рабочей ветки в Trunk
Харьков 2014 Artezio
// Рекомендация: Создавайте новую ветвь только тогда, когда
вы хотите залить код в систему контроля версий , и не
существует ветви, которую можно для этого использовать, не
нарушив ее политику
При публикация в trunk идет полная
синхронизация двух веток.

7. Проблемы синхронизации с Trunk
1. Что если наша команда параллельно реализует несколько задач?
2. Что если другие команды тоже делают публикацию в trunk?
Харьков 2014 Artezio

8. Возможные решения параллельной
разработки в команде
• Не разрабатывать параллельно. Постараться сфокусировать работу
всей команды на одной задаче.
• В командной ветке может находиться только одно не готовое задание.
Все остальные могут отправить только готовые задачи.
• В командной ветке может находиться только одно не готовое задание.
Все остальные могут отправлять части задания, которые никак не
повлияют на текущую задачу.
Харьков 2014 Artezio
// Правило: Тот кто вносит изменения в trunk отвечает за то, что он
остается готовым к поставке, включая всю предыдущую функциональность!
// Правило: Постоянно синхронизируйте ваш код с рабочей ветвью (так
часто, как это возможно)

9. Правила работы в командной ветке
• Тот кто работает над самой приоритетной задачей – Король, или ведущий разработчик.
• Все остальные в команде – Слуги, или просто разработчики.
• Вы хотите быть Королем. Постарайтесь найти способ принять участие в работе над
самой приоритетной задачей.
• Когда Королю нужна помощь, Слуги немедленно предлагают ему свои услуги.
• Слуга не может мешать Королю.
• Слуга не может заливать в рабочую ветвь код, не готовый к поставке. Король может
заливать в ветку команды все, что он хочет.
• Как только готова самая приоритетная задача, Королем становится тот, кто реализует
следующую по приоритетности задачу.
Харьков 2014 Artezio

10. Подхват изменений из trunk
День в команде начинается с того, что выбранный член команды
должен подхватывать изменения из trunk в рабочую ветку
команды. Любые конфликты версий считаются первостепенными
задачами.
Харьков 2014 Artezio
// Правило: Сливайте код из trunk-а в вашу рабочую ветвь каждый день
// Правило: Решайте конфликты в ветви, которая менее стабильна

11. Одновременная синхронизация с trunk
// Правило: Заливайте код из вашей рабочей ветви в trunk на
регулярной основе, например, каждый раз, когда готово задание. Не
ждите до конца итерации!
// Побочный эффект: Побеждает тот, кто первым заливает код в
trunk!
Харьков 2014 Artezio

12. Ветви релизов
Харьков 2014 Artezio
// Правило: Сливайте код в trunk по иерархии создания веток

13. Общая картина
Харьков 2014 Artezio
// Правило: Делаем слияние сверху вниз, копируем снизу вверх
// Правило: Всегда принимайте стабилизирующие изменения.
Никогда не навязывайте дестабилизирующие изменения

14. Subversion механизмы для реализации шаблона управления
версиями
Харьков 2014 Artezio

15. Mercurial децентрализованное
управление версиями
Харьков 2014 Artezio

16. GIT
реализация
шаблона
управления
версиями
Харьков 2014 Artezio

17. Вопросы
Контакты: andrus.god@gmail.com
Ресурсы:
• http://www.infoq.com/articles/agile-version-control
• http://agilerussia.ru/practices/version-control-with-multiple-teams/
• http://scrum.org.ua/wp-content/uploads/2008/12/scrum_xp-from-the-
trenches-rus-final.pdf
• http://nvie.com/posts/a-successful-git-branching-model/
• http://habrahabr.ru/post/106912/
• http://hginit.com/
• http://1drv.ms/NaYdpD
Харьков 2014 Artezio