Дао версионности

Предыстория

На третьем курсе зав.каф. Захаров Ю.Н. отправил меня помогать старшекурснику в написании визуализатора треков частиц. С меня было программирование, со старшекурсника математическое обеспечение. В тот момент у меня откуда-то появилось знание (возможно с хабра), что Ъ-пацаны в командной работе юзают контроль версий. State-of-the-art на тот момент был subversion, mercurial с git, хоть и родились но пугали кучей проблем (возможно отталкивало отсутствие опыта). Я заинитил репозиторий, выдернул из меркуриала консольные утилиты и начал его юзать. Использовал в одиночку, хоть и не долго.



В это же время устроился на работу, где было сложно с программистами и царил первобытный хаос. Спустя несколько месяцев появился DBA и еще один разработчик. И мы успешно занимались разработкой в течении почти двух лет, без проблем мерджа изменения при помощи TotalCommander. Все изменилось 22 марта 2010 года. За неделю до этого появился третий программист и сложность мерджа резко возросла. После недели кошмара и непрерывного решения конфликтов, новичок сказал: хватит это терпеть, давайте заюзаем svn, что мы и сделали, успешно перенеся всю разработку под контроль версий и подняв trac, который легко интегрировался с svn.

Свет в конце тоннеля

21 ноября 2010 года у нас стартанул минипроект. На нем мы решили попробовать распределенную систему контроля версий. Выбор пал на mercurial. Распределенности там никакой не получилась, поскольку проект тихо умер спустя две недели так и не дожив до мерджа на 13 коммите. Больше всего привелекло в нем отсутствие необходимости в централизованном сервере, а hg serve казалась пределом мечтаний. С тех пор я использую исключительно mercurial, git, который попробовал использовать для собственного мини-проекта, так и не взлетел. Особенно убило монструозная установка, приносящая на винду всю командную оболочку линукса, плюс танцы с ssh-ключом привили стойкое отвращение.

0 этап

На новой работе я сразу начал с hg init и проекта в bitbucket, который хоть и не был так наворочен, как github, но позволял создавать приватные репозитории для маленьких команд. Более-менее начал даже использовать ветки. Тем не менее, одиночная разработка не сильно отличалась от работы с централизованным репозиторием в небольшой команде.

1 этап

Горыныч

Еще раз сменив работу, я попал четвертым в команду в самый разгар кодинга. У нас был центральный репозиторий, через который шел обмен ревизиями. Многоголовая разработка в одной ветке, постоянные мерджи и конфликты с взаимо-исключающими изменениями - все это не могло длиться долго. Соседи тоже использовали mercurial, но мы так и не смогли объяснить что мы хотим получить, а используемые ими инструменты (например collapse) нам не хотелось применять. Понять как правильно работать с rebase мы тогда не смогли.

2 этап

Мердж без единого конфликта

Вскоре терпение лопнуло и каждый разбежался по своим веткам, доверив разовый мердж, по завершению задачи, тимлиду. История сразу же выпрямилась, исчезли регулярные мерджи недописанного кода. С требованием вливать в главную ветку только работающий код - default сразу стал стабильно рабочим. Тем не менее понимание стабилизации кода и итераций в разработке еще не было.

3 этап

Посетив кодефест 2012, мы услышали про GitFlow, который просто перевернул понимание командной работы над серьезным, долгоживущим проектом. Мы сразу адаптировали его под наши меркуриальные реалии и стали активно использовать. Столкнулись с одной единственной проблемой: массовое закрытие веток-фич - но это тема отдельного разговора.

4 этап

Не так давно обратил внимание, что открывать ветки под микрофиксы лениво, да и вообще наконец разобрались экстеншеном rebase, что позволило вести разработку в одной ветке-фиче, не порождая Горыныча и не плодя ненужных веток. Достаточно было только одного требования: последний коммит ребейза должен быть рабочим, чтобы не ломать коллегам код, когда они спулят из центрального репозитория.

Продолжение следует

 

P.S. Rebase подробно обсуждается в radio-t #330 и #339