Распределенный контроль версий

В разработке программного обеспечения распределенный контроль версий (также известный как распределенный контроль версий ) — это форма контроля версий , при которой вся база кода , включая ее полную историю, отражается на компьютере каждого разработчика. ^[1] По сравнению с централизованным контролем версий это обеспечивает автоматическое разветвление и слияние управления , ускоряет большинство операций (кроме отправки и извлечения), улучшает возможности работы в автономном режиме и не зависит от единого хранилища резервных копий. ^[1]^[2]^[3] Git , самая популярная в мире система контроля версий. ^[4] это распределенная система контроля версий.

В 2010 году автор разработки программного обеспечения Джоэл Спольски описал распределенные системы контроля версий как «возможно, самое большое достижение в технологии разработки программного обеспечения за [последние] десять лет». ^[2]

Распределенный и централизованный

Распределенные системы контроля версий (DVCS) используют одноранговый подход к контролю версий, в отличие от клиент-серверного подхода централизованных систем. Распределенный контроль версий синхронизирует репозитории путем передачи исправлений от узла к узлу. Не существует единой центральной версии кодовой базы; вместо этого у каждого пользователя есть рабочая копия и полная история изменений.

К преимуществам DVCS (по сравнению с централизованными системами) относятся:

Позволяет пользователям продуктивно работать без подключения к сети.
Обычные операции (такие как фиксации, просмотр истории и откат изменений) выполняются быстрее для DVCS, поскольку нет необходимости связываться с центральным сервером. ^[5] При использовании DVCS связь необходима только при обмене изменениями между другими узлами.
Разрешает частную работу, поэтому пользователи могут использовать свои изменения даже для ранних черновиков, которые они не хотят публиковать. ^{[ нужна ссылка ]}
Рабочие копии эффективно функционируют как удаленные резервные копии, что позволяет избежать использования одной физической машины как единой точки отказа. ^[5]
Позволяет использовать различные модели разработки, например использование ветвей разработки или модели командира/лейтенанта. ^[6]
Позволяет централизованно управлять «релизной версией» проекта. ^{[ нужна ссылка ]}
В проектах программного обеспечения FOSS гораздо проще создать ответвление проекта , который застопорился из-за конфликтов руководства или разногласий в дизайне.

К недостаткам DVCS (по сравнению с централизованными системами) относятся:

Первоначальная выдача репозитория происходит медленнее по сравнению с выдачей в централизованной системе контроля версий, поскольку все ветки и история изменений по умолчанию копируются на локальный компьютер.
Отсутствие механизмов блокировки, которые являются частью большинства централизованных VCS и по-прежнему играют важную роль, когда речь идет о неслияемых двоичных файлах, таких как графические ресурсы или слишком сложные однофайловые двоичные файлы или пакеты XML (например, офисные документы, файлы PowerBI, SQL Server). Пакеты Data Tools BI и т. д.). ^{[ нужна ссылка ]}
Дополнительное хранилище, необходимое для того, чтобы каждый пользователь имел полную копию всей истории кодовой базы. ^[7]
Повышенная доступность базы кода, поскольку у каждого участника есть локально уязвимая копия. ^{[ нужна ссылка ]}

Некоторые изначально централизованные системы теперь предлагают некоторые распределенные функции. 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]

См. также

Контроль версий
Список программного обеспечения для контроля версий
Сравнение программного обеспечения для контроля версий
Категория:Программное обеспечение, использующее распределенный контроль версий
Клон репозитория
Git , DVCS с открытым исходным кодом , разработанный для разработки ядра Linux.
Mercurial — кроссплатформенная система, похожая на Git.
Fossil — распределенная система контроля версий, система отслеживания ошибок и вики-программное обеспечение.
Биткипер
ГНУ Базар
Concurrent Versions System , предшественник распределенных систем контроля версий.
TortoiseHg — графический интерфейс для Mercurial.
Code Co-op — одноранговая система контроля версий.

Ссылки

^ Перейти обратно: ^а ^б Чакон, Скотт; Штрауб, Бен (2014). «О контроле версий» . Pro Git (2-е изд.). Апресс. Глава 1.1 . Проверено 4 июня 2019 г.
^ Перейти обратно: ^а ^б Спольски, Джоэл (17 марта 2010 г.). «Распределенный контроль версий никуда не денется, детка» . Джоэл о программном обеспечении . Проверено 4 июня 2019 г.
^ «Введение в распределенный контроль версий (иллюстрировано)» . www.betterexplained.com . Проверено 7 января 2018 г.
^ Перейти обратно: ^а ^б «Популярность систем контроля версий в 2016 году» . www.rhodecode.com . Проверено 7 января 2018 г.
^ Перейти обратно: ^а ^б О'Салливан, Брайан. «Распределенный контроль версий с помощью Mercurial» . Проверено 13 июля 2007 г.
^ Чакон, Скотт; Штрауб, Бен (2014). «Распределенные рабочие процессы» . Pro Git (2-е изд.). Апресс. Глава 5.1.
^ «Что такое контроль версий: централизованный или DVCS» . www.atlassian.com . 14 февраля 2012 года . Проверено 7 января 2018 г.
^ Джонатан Аллен (08 февраля 2017 г.). «Как Microsoft решила проблему Git с большими репозиториями» . Проверено 6 августа 2019 г.
^ Упадхайе, Анну (22 февраля 2023 г.). «Централизованное и распределенное управление версиями» . ГФГ . Проверено 4 апреля 2024 г.
^ Сийбрандий, Сице (29 сентября 2014 г.). «Поток GitLab» . ГитЛаб . Проверено 4 августа 2018 г.
^ Перейти обратно: ^а ^б Джонсон, Марк (8 ноября 2013 г.). «Что такое запрос на включение?» . Оаааач . Проверено 27 марта 2016 г.
^ «Использование запросов на включение» . Гитхаб . Проверено 27 марта 2016 г.
^ «Оформление запроса на извлечение» . Атласиан . Проверено 27 марта 2016 г.
^ Перейти обратно: ^а ^б Макалистер, Нил. «Ошибка BitKeeper Линуса Торвальдса» . Инфомир . Проверено 19 марта 2017 г.

Внешние ссылки

Эссе о различных системах контроля версий , особенно раздел «Централизованный и децентрализованный SCM»
Введение в распределенные системы контроля версий - статья IBM Developer Works

[git-scm-1] Перейти обратно: ^а ^б Чакон, Скотт; Штрауб, Бен (2014). «О контроле версий» . Pro Git (2-е изд.). Апресс. Глава 1.1 . Проверено 4 июня 2019 г.

[Joel_2010-2] Перейти обратно: ^а ^б Спольски, Джоэл (17 марта 2010 г.). «Распределенный контроль версий никуда не денется, детка» . Джоэл о программном обеспечении . Проверено 4 июня 2019 г.

[3] «Введение в распределенный контроль версий (иллюстрировано)» . www.betterexplained.com . Проверено 7 января 2018 г.

[:1-4] Перейти обратно: ^а ^б «Популярность систем контроля версий в 2016 году» . www.rhodecode.com . Проверено 7 января 2018 г.

[OSullivan-5] Перейти обратно: ^а ^б О'Салливан, Брайан. «Распределенный контроль версий с помощью Mercurial» . Проверено 13 июля 2007 г.

[6] Чакон, Скотт; Штрауб, Бен (2014). «Распределенные рабочие процессы» . Pro Git (2-е изд.). Апресс. Глава 5.1.

[7] «Что такое контроль версий: централизованный или DVCS» . www.atlassian.com . 14 февраля 2012 года . Проверено 7 января 2018 г.

[8] Джонатан Аллен (08 февраля 2017 г.). «Как Microsoft решила проблему Git с большими репозиториями» . Проверено 6 августа 2019 г.

[9] Упадхайе, Анну (22 февраля 2023 г.). «Централизованное и распределенное управление версиями» . ГФГ . Проверено 4 апреля 2024 г.

[gitlab-merge-req-10] Сийбрандий, Сице (29 сентября 2014 г.). «Поток GitLab» . ГитЛаб . Проверено 4 августа 2018 г.

[ossw-11] Перейти обратно: ^а ^б Джонсон, Марк (8 ноября 2013 г.). «Что такое запрос на включение?» . Оаааач . Проверено 27 марта 2016 г.

[12] «Использование запросов на включение» . Гитхаб . Проверено 27 марта 2016 г.

[13] «Оформление запроса на извлечение» . Атласиан . Проверено 27 марта 2016 г.

[:0-14] Перейти обратно: ^а ^б Макалистер, Нил. «Ошибка BitKeeper Линуса Торвальдса» . Инфомир . Проверено 19 марта 2017 г.

[1]

[2]

[3]

[4]

[5]

[6]

[7]

[8]

[9]

[10]

[11]

[12]

[13]

[14]