В разработке программного обеспечения распределенный контроль версий (также известный как распределенный контроль версий ) — это форма контроля версий , при которой полная кодовая база , включая ее полную историю, зеркалируется на компьютере каждого разработчика. [1] По сравнению с централизованным контролем версий, это обеспечивает автоматическое управление ветвлением и слиянием , ускоряет большинство операций (кроме отправки и получения), улучшает возможность работы в автономном режиме и не зависит от одного места для резервных копий. [1] [2] [3] Git , самая популярная в мире система контроля версий, [4] является распределенной системой контроля версий.
В 2010 году автор статей о разработке программного обеспечения Джоэл Спольски описал распределенные системы контроля версий как «возможно, самое большое достижение в технологии разработки программного обеспечения за [последние] десять лет» [2] .
Распределенные системы управления версиями (DVCS) используют одноранговый подход к управлению версиями, в отличие от клиент-серверного подхода централизованных систем. Распределенный контроль версий синхронизирует репозитории, передавая исправления от однорангового узла к одноранговому узлу. Не существует единой центральной версии кодовой базы; вместо этого у каждого пользователя есть рабочая копия и полная история изменений.
Преимущества DVCS (по сравнению с централизованными системами) включают в себя:
К недостаткам DVCS (по сравнению с централизованными системами) относятся:
Некоторые изначально централизованные системы теперь предлагают некоторые распределенные функции. Team Foundation Server и Visual Studio Team Services теперь размещают централизованные и распределенные репозитории управления версиями через хостинг Git.
Аналогичным образом, некоторые распределенные системы теперь предлагают функции, которые смягчают проблемы времени извлечения и затрат на хранение, например, виртуальная файловая система для Git , разработанная Microsoft для работы с очень большими кодовыми базами, [8] которая предоставляет виртуальную файловую систему, загружающую файлы в локальное хранилище только по мере необходимости.
Распределенная модель, как правило, лучше подходит для крупных проектов с частично независимыми разработчиками, такими как проект ядра Linux, поскольку разработчики могут работать независимо и отправлять свои изменения для слияния (или отклонения). Эта гибкость позволяет использовать пользовательские рабочие процессы по внесению исходного кода, такие как рабочий процесс интегратора , который является наиболее широко используемым. В отличие от централизованной модели, где разработчики должны сериализовать свою работу, чтобы избежать проблем с разными версиями, в распределенной модели разработчики могут клонировать всю историю кода на свои локальные машины. Сначала они фиксируют свои изменения в своих локальных репозиториях, создавая «наборы изменений», прежде чем отправлять их в главный репозиторий. Такой подход позволяет разработчикам работать локально и автономно, что делает его более удобным для распределенных команд. [9]
В действительно распределенном проекте, таком как Linux , каждый участник поддерживает свою собственную версию проекта, при этом разные участники размещают свои собственные соответствующие версии и вносят изменения от других пользователей по мере необходимости, что приводит к общему консенсусу, возникающему из нескольких различных узлов. Это также упрощает процесс «разветвления», поскольку все, что требуется, — это один участник прекратить принимать запросы на извлечение от других участников и позволить кодовым базам постепенно разрастаться.
Однако такую схему сложно поддерживать, в результате чего многие проекты выбирают переход к парадигме, в которой один участник является универсальным «вышестоящим», репозиторием, из которого почти всегда извлекаются изменения. В рамках этой парадигмы разработка несколько рецентрализуется, поскольку теперь у каждого проекта есть центральный репозиторий, который неформально считается официальным репозиторием, управляемым сопровождающими проекта коллективно. В то время как распределенные системы контроля версий позволяют новым разработчикам легко «клонировать» копию репозитория любого другого участника, в центральной модели новые разработчики всегда клонируют центральный репозиторий, чтобы создать идентичные локальные копии кодовой базы. В рамках этой системы изменения кода в центральном репозитории периодически синхронизируются с локальным репозиторием, и после завершения разработки изменение должно быть интегрировано в центральный репозиторий как можно скорее.
Организации, использующие этот шаблон централизации, часто предпочитают размещать центральный репозиторий на стороннем сервисе, таком как GitHub , который обеспечивает не только более надежную работу, чем самостоятельные репозитории, но и может добавлять централизованные функции, такие как отслеживание ошибок и непрерывная интеграция .
Вклады в репозиторий исходного кода, использующий распределенную систему управления версиями, обычно вносятся посредством запроса на извлечение , также известного как запрос на слияние . [10] Участник запрашивает, чтобы сопровождающий проекта извлек изменение исходного кода, отсюда и название «запрос на извлечение». Сопровождающий должен объединить запрос на извлечение, если вклад должен стать частью исходной базы. [11]
Разработчик создает запрос на извлечение, чтобы уведомить сопровождающих о новом изменении; с каждым запросом на извлечение связана ветка комментариев. Это позволяет проводить целенаправленное обсуждение изменений кода . Отправленные запросы на извлечение видны всем, у кого есть доступ к репозиторию. Запрос на извлечение может быть принят или отклонен сопровождающими. [12]
После проверки и одобрения запроса на включение он объединяется с репозиторием. В зависимости от установленного рабочего процесса код может потребовать тестирования перед включением в официальный релиз. Поэтому некоторые проекты содержат специальную ветку для объединения непротестированных запросов на включение. [11] [13] Другие проекты запускают автоматизированный набор тестов для каждого запроса на включение, используя инструмент непрерывной интеграции , и рецензент проверяет, что любой новый код имеет соответствующее тестовое покрытие.
Первые системы DVCS с открытым исходным кодом включали Arch , Monotone и Darcs . Однако системы DVCS с открытым исходным кодом никогда не были особенно популярны до выпуска Git и Mercurial .
BitKeeper использовался при разработке ядра Linux с 2002 по 2005 год. [14] Разработка Git , в настоящее время самой популярной в мире системы контроля версий, [4] была вызвана решением компании, создавшей BitKeeper, отменить бесплатную лицензию, которой ранее воспользовались Линус Торвальдс и некоторые другие разработчики ядра Linux. [14]