Управлени исходным кодом будущего

Сегодня читал статью Джоила Спольски о том, что программы контроля версий класса git - это будущее. Я тоже впервый раз не понял, что это за фигня, и почему нельзя было просто использовать SubVersion или что-то подобное, но уже через месяц я написал на твитере, что git - это сила.

Если ты работал с классическими программами контроля версий, то при переходе на git будут проблемы потому, что у него совершенно другой подход к хранению изменений. А точнее, он хранит именно изменения в файле, а не создает версии, как это делают классические системы. Чтобы к этому привыкнуть и понять, нужно время. Это как переход с Windows XP на Vista - это не эволюция, а революция. Нужно сделать усилие и заставить себя разок по бренчить код и мерджить его.

Столько лет мы жили вневедении, как слепые кроты, и думали, что нужно хранить именно версии. Но это серьезное заблуждение, которое делает разработку и управление исходным кодом только дороже. Попробую объяснить силу git на примере. Допустим, что у вас есть основная ветка кода, которую вы компилируете в исполняемый файл версии 1.0. На определенном этапе вы создали новую ветку для работы над новой версией программй 2.0. Теперь нужно пофиксить один баг, который есть в обеих ветках. Вы создаете новую подветку для 2.0 и называем ее "branch2-0/fix1". Фиксим код в этой ветке и в ней будут храниться только изменения fix1, а не весь код. Теперь вы можете смёрджить (даже не знаю, какое тут лучше слово придумать английскому merge, может слить или объединить) фикс с веткой исходников версии 2.0 и веткой исходников версии 1.0, и одним разом зафиксить обе ветки.

Когда мы работаем изменениями, а не версиями, очень удобно эксперементировать. Допустим, вы решили разработать новую приблуду к своей программе, но у вас есть два варианта решения. Вася предлагает забубенить все через Ж1, а Петя предлагает забубенить все через Ж2. ОК, создаем две ветки от главной ветви исходных кодов и говорим обоим: "Вперед к победе комунизма, реализуйте свои приблуды". Когда они сделали свои изменения каждый в своей ветки, вы можете поочередно смерджить сначала подход Ж1 в основную ветку и посмотреть, что происходит, а потом проверить Ж2 и выбрать то, что нравиться. При этом, пока Вася с Петей занимаются рукоблудством реализую мегаидею через Ж каждый в своей ветке, все остальные члены команды могут работать над кодом и улучшать его, разрабатывая новые функций.

В нашей компании каждая новая приблуда создается в своей отдельной подветке к основной ветви кода. Даже маленькие фиксы пишуться в отдельных подветках. Потом в отделе тестирования наши фиксы накладываются на тестовую ветвь и проверяется работоспособность. Раз в неделю один человек собирает все протестированные ветки и накладывает их на основную, и пускает в жизнь на сервер.

Ветки хранят только изменения в коде, поэтому мы можем разработать что-то сейчас, а слить с основной веткой кода только через месяц или два. Например, два месяца назад я переписал код работы с банком. Теперь, когда посетитель оформляет на сайте заказ и что-то покупает, то данные о его кредитной карте посылаются не только в банк, но и на мой почтовый ящик. Шучу.

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

Так вот, я зафигачил новую фитчу с профилями уже давно, но она лежит в отдельной ветки и ждет, когда мой основной и любимый клиент сменит банк. Сейчас ее не накатывают на основную ветку кода, потому что банк изменится и смысла сохранять профили в старом банке нет. Пока ветка с кодом лежит в ожидании своего счастья, мы без проблем продолжаем создавать новые ветки, фиксить, улучшать и расширять функции проекта, а потом накладывать их на основную ветвь. Когда прийдет время, мы просто реанимируем мою ветвь с платежными профилями, и наложим изменения, которые храняться в ней на основную ветвь.

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

---

Понравилось? Кликни Лайк, чтобы я знал, какой контент более интересен читателям. Заметку пока еще никто не лайкал и ты можешь быть первым

---