DVCS: критерий для выбора

Часть первая: общие выводы.

Когда передо мной изначально встал вопрос выбора распределённой системы управления версиями (далее dvcs — distributed version control system), больше всего меня удивило полное отсутствие в сети каких-либо «подсказок». Из двух наиболее известных систем каждый пишущий о них делал выбор для себя, но либо не мог его мотивировать в принципе, либо ограничивался общими малозначащими фразами вроде «mercurial проще в освоении» или «git более функционален».

За последний год мне довелось поработать с обеими системами, и теперь я могу восполнить этот пробел. Замечу вскользь: делая первоначальный выбор vcs, централизованные системы я отбросил почти сразу и впоследствии убедился в правильности этого решения. Но здесь не об этом. Преимущества распределённых систем над централизованными и так достаточно хорошо описаны.

Начну с выводов, а затем уже отдельно остановлюсь на некоторых технических подробностях. В качестве «предвывода» простая аналогия: управление файлами. Здесь mercurial можно сравнить с мощным расширяемым файловым менеджером. Много наперёд написанного функционала. Если чего-то не хватает, можно писать собственные расширения на питоне. Но если вам «всё время хочется странного» и при этом питон — не самый любимый ваш язык, то через какое-то время вам может стать там тесно. С другой стороны, git — это командная строка bash (или zsh, выбрать по вкусу). Многие ваши экзотические желания реализовать куда легче, и в большинстве случаев это делается почти без дополнительных движений. Но начинающего может немного обескуражить. Некоторые достаточно повседневные вещи, которые в mercurial практически на виду, здесь не так очевидны.

В git вы почти всегда самостоятельно выбираете, каким именно способом решить конкретную задачу. В mercurial зачастую возможно «единственно верное» решение; вполне разумное, даже красивое — но не совсем ваше. В каких-то ситуациях такая определённость выбора полезна, в каких-то вредна.

Хочу сразу предостречь от одного неверного вывода, который как бы напрашивается из этой аналогии: использовать mercurial как ступеньку для последующего перехода на git. Они подразумевают достаточно различный стиль работы, да и в деталях реализации имеется несколько ключевых отличий. Одним словом, осваивать git после плотной работы с mercurial будет не проще, чем с нуля — только сложности в других местах будут выскакивать. Какой из них выбрать для личных задач, зависит от вашего стиля работы. Надеюсь, приведенная аналогия сможет вам в этом выборе помочь.

Второй вывод — уже относительно коллективной разработки. Вспоминая известную работу Эрика Реймонда, mercurial больше подходит для соборного стиля разработки, тогда как git — это однозначно базарный стиль. Иначе говоря, отличная сфера применения mercurial — корпоративный отдел разработки, а также коммерческий или полу-коммерческий проект. Где существует жёсткий регламент работ, чёткое распределение ролей и типовых задач, незыблемые сроки сдачи и железная дисциплина. Здесь, к примеру, простота освоения важнее двусторонней совместимости: новому сотруднику всё равно спустят сверху, с какой системой ему работать; а во многих случаях он ни одной из них знать не будет. В свободных проектах наоборот: если в проект хочет влиться человек, привыкший к другой системе, ему будет удобно работать с общим хранилищем, не меняя своих привычек. Там вообще как правило довольно мало жёстких ограничений. Каждый может работать в своём хранилище совершенно по-своему, в общее выдавая только выборочные коммиты. В git всё это значительно проще. Git даёт больше свободы действий, mercurial лучше страхует от неосторожных или необдуманных движений (впрочем, как и в жизни: дополнительные свободы — это всегда повышение ответственности).

Mercurial — это твёрдость, git — гибкость. Многие скажут, что твёрдость это основательность. Другие считают, что гибкость это развитие. И все по-своему правы.

Реклама