Стоит ли использовать альтернативу Git?

Git невероятно популярен и поддерживается почти везде. Поскольку это практически система контроля версий по умолчанию, возникает вопрос, какие у вас есть альтернативы? Стоит ли их рассматривать и чем они отличаются?

Обратите внимание, что в этой статье обсуждаются альтернативы git в качестве программного обеспечения для контроля версий. Если вы просто ищете альтернативу размещенному сервису, такому как Github, вместо этого вы можете прочитать наше руководство по размещенным решениям Git.

Недостатки Git

Чтобы лучше понять ограничения Git, мы должны начать с того, что он делает правильно.

Git использует распределенную модель управления версиями; локальный репозиторий каждого пользователя на самом деле не подключен к какому-либо центральному серверу. Этот пользователь может выйти из сети, внести кучу изменений, и никто другой не увидит эти изменения, пока они не будут отправлены на удаленный компьютер. Это работает очень хорошо для разработки программного обеспечения с открытым исходным кодом; Git намного быстрее для большинства действий, так как отдельные пользователи могут клонировать репозиторий и вносить свои собственные небольшие изменения, не беспокоясь о том, что делают другие люди.

Эти изменения могут быть интегрированы в главный репозиторий с помощью запросов на вытягивание (пользователь, отправляющий запросы на изменение в главный репозиторий, чтобы получить коммиты из своей частной версии репо), и обновления, отправленные от аутентифицированных пользователей, при условии, что все конфликты слияния разрешены должным образом.

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

Не поймите нас неправильно — это все еще фантастика, особенно в сочетании с внешним программным обеспечением для отслеживания проблем и конвейерами CI/CD, с чем такие сервисы, как GitLab и BitBucket, справляются довольно хорошо. Но Git не был создан для корпоративного управления исходным кодом, где вы почти всегда будете иметь центральный сервер, действующий как главный репозиторий. Это требует очень правильного использования (и часто внешних инструментов), чтобы быть эффективным для agile-команд, вносящих много изменений в код.

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

Кроме того, если у вас несколько проектов, вам, вероятно, не нужен исходный код для всего, видимого каждому разработчику. В Git эта проблема обычно решается созданием отдельных репозиториев для каждого проекта, что работает очень хорошо, но не идеально, если вам нужно интегрировать их вместе в одну связную часть. Благодаря централизованному контролю версий вы можете предоставить доступ только к определенным папкам.

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

Основная альтернатива: централизованный контроль версий

Наиболее распространенное различие между Git и альтернативами — отказ от децентрализованного контроля версий в пользу центрального авторитетного сервера. Apache Subversion и Team Foundation Version Control — это основные системы управления версиями, использующие этот формат.

Для сравнения, в системе DVC у каждого пользователя есть локальный репозиторий, в котором они фиксируют свои изменения. Когда они будут готовы отправлять обновления на главный сервер, другие пользователи могут иметь разные версии одного и того же файла, над которым вы работаете. Это известно как конфликт слияния, и это очень распространенная (хотя и легко разрешимая) проблема с Git.

В централизованном контроле версий (CVC), таком как Apache Subversion, есть один серверный репозиторий и множество клиентов, подключенных напрямую к нему. Если вы вносите изменения в файл, этот файл обновляется на компьютерах других пользователей всякий раз, когда они обновляются. Коммиты выполняются непосредственно на главном сервере.

Для предотвращения конфликтов слияния в большинстве систем CVC используются блокировки. Если пользователь А желает работать с файлом и не хочет, чтобы кто-то еще возился с ним, он может заблокировать файл до тех пор, пока не закончит работу, не позволяя другим пользователям делать то же самое. Это не требуется в Subversion, и конфликты слияния все еще могут возникать, но они менее случайны.

Проблема в основном смягчается с помощью ветвления и локальных копий, которые позволяют нескольким пользователям работать над своими собственными версиями в течение продолжительных периодов времени перед объединением изменений.

Еще одна замечательная функция централизованного управления версиями — управление разрешениями; вместо предоставления доступа ко всему репозиторию CVC позволяет легко разделить доступ к определенным папкам. Управление версиями Team Foundation работает почти так же, как Subversion, позволяя детализировать делегирование разрешений вплоть до уровня файлов.

Все эти функции делают централизованное управление версиями жизнеспособной альтернативой DVC. В конце концов, Google размещает весь свой код в одной массивной централизованной системе, намного большей, чем любая распределенная система. Конечно, кодовая база Windows представляет собой репозиторий Git объемом 300 ГБ, но он использует подключаемый модуль виртуальной файловой системы Git, который позволяет пользователям загружать только те файлы, которые им нужны, и ничего больше.

Однако одним из недостатков Subversion является то, что ему часто приходится много копировать и скачивать, что может сделать его намного медленнее, чем локальная модель Git.

Другие альтернативы

Хотя мы сосредоточились на централизованных системах управления версиями, которые могут заменить Git, есть и другие распределенные системы управления версиями, которые вы можете использовать, в первую очередь Mercurial.

Mercurial немного проще в использовании, чем Git, и они оба примерно одинаковы с точки зрения производительности, но в целом они очень похожи. На самом деле, нет особых причин выбирать Mercurial вместо Git, кроме личных предпочтений, которые, вероятно, не должны диктовать корпоративные решения.

Mercurial раньше был опцией в BitBucket, но недавно они прекратили его поддержку, основная причина в том, что Git просто намного популярнее и широко поддерживается. Это практически стандартная система контроля версий, и если альтернативой не является радикальное изменение модели (например, CVC), ее не стоит рассматривать.