Git как альтернатива Subversion

В посте корпоративного блога, перевод которого идёт ниже, один из основных разработчиков Digg весьма эмоционально описывает свои впечатления от перехода от Subversion к Git и рассказывает о том насколько увеличилась продуктивность команды данного проекта. За последние 12-16 месяцев в ряды команды Digg серьёзно расширились. Инженерный отдел увеличился в целых три раза, а к нему добавились ещё и отдельные QA и R&D команды. Если раньше мы выпускали код раз в три-четыре месяца, то сейчас релизы выходят фактически ежедневно. Мы столкнулись с рядом препятствий в этот переходный период, некоторые удалось легко преодолеть, решение других же далось с трудом. Нам пришлось изменить некоторые из наших процессов, освоить новые технологий, и многое изменить в менталитете наших разработчиков. Когда я начинал работать в Digg, вся наша команда девелоперов работала вместе над одним проектом – время от времени все собирались на день или два в конференц-зале, искали и фиксили баги, после чего выпускался релиз, и команда переключалась на следующий проект. Сейчас же мы ведём разработку сразу нескольких проектов параллельно, и каждая функция создаваемого решения проходит проверку QA отделом, после чего она и выходит в свет. Вначале мы использовали Subversion. Мы проверяли, разветвляли, коммитили, сливали и тэгировали. Это было далеко от совершенства и не сильно всех радовало, но это то, что у нас было. И это работало, в основном. Это была простая для понимания система и очень проста в использовании. Но только до определённых масштабов. Наша инженерная группа росла, все больше и больше работы делалось в одной и той же баз кода, и всё чаще мы мешали и, так сказать, наступали на ноги друг другу. Процесс интеграции (объединения функций для релиза) длился по несколько дней и приводил к появлению множества конфликтов в коде. Человек, который осуществлял сборку, пытался разобраться самостоятельно с проблемой или же обращался к девелоперу, непосредственно реализовывавшему какую-либо функцию, чтобы отследить, в чём именно конфликт и какой код следует править, а какой сохранить. Всё это в обоих случаях приводило к множеству багов, а также буквально к исчезновению части кода. И это стоило нам времени, денег и влияло на наших пользователей, а ко всему этому мы относимся всегда серьёзно. Мы знали, что должен быть какой-то другой, лучший, путь и стали его искать. Сначала мы пытались перейти от Subversion 1.4 к 1.5, в котором есть функция отслеживания сборок. Мы надеялись, что она сделает наш процесс интеграции куда более простым. Однако после того как мы поработали с Subversion 1.5 несколько недель мы поняли, что “merge tracking” в данном случае скорее миф нежели реальность. В теории всё хорошо, а на практике – толку ноль.

И тут пришёл Git

Тогда все заговорили о Git. Некоторые из нас слышали о нём, и только пара человек вообще в глаза видела и использовала, но в основном только для своих личных проектов. Оказалось, что Git - это будет next big thing, потому что он действительно очень и очень крутой. Жизнь наших инженеров стала куда проще, а сами они гораздо продуктивнее. Это был словно стакан холодного лимонада в жаркий день. Мы сделал один осторожный глоток – вкус напитка оказался весьма неплохим, потом второй, а потом с удовольствием одним махом осушили весь стакан. Так чем же Git так замечателен? Ну, в двух словах, просто потому что он мощный и распределённый. Он позволяет решать сложные задачи в несколько команд. Он делает такие вещи, как ветвление и сборка практически полностью бездумным и ненапряжным. Он фактически позволяет вам переписывать историю. Это действительно позволяет каждому инженеру работать так, как они хотят. И когда они готовы, выпускать свой код на всеобщее рассмотрение. Управление кодом и changeset'ами здесь так резко отличаются от Subversion, что это приводит прямо таки к ментальному сдвигу, и вы, наконец, начинаете понимать, что вообще такое система управления версиями. И поверьте мне, это круто. Но есть у Git и свои недостатки. Сначала может будет трудно понять, что действительно происходит за кулисами, когда вы запускаете команду, и если что-то пойдет не так, вы действительно должны понимать, как Git работает изнутри, чтобы исправить свою ошибку. Он также ещё не конца отполирован, у него нет хорошего графического интерфейса, и выдаваемые сообщения об ошибках, вы получаете, когда команде не удается выполнить операцию, вполне могут быть написаны на санскрите. Но, несмотря на всё это, он работает. И работает так, что после перехода на Git, нам удалось сократить время на интеграцию от нескольких дней до нескольких минут. Буквально с 1-2 дней до примерно 30 минут. И после интеграции у нас теперь куда больше уверенности в том, что сборка осуществлено правильно. Мы также теперь в состоянии выпускать код на ежедневной основе с минимальными усилиями, что было очень тяжело сделать, используя с Subversion. Оригинал