Войти
В разработке программного обеспечения, распределенный контроль версий (также известный как распределенный контроль версий ) - это форма контроля версий, в которой полная кодовая база, включая его полную историю, отображается на каждом компьютере разработчика. Это обеспечивает автоматическое управление ветвлением и объединением, ускоряет большинство операций (кроме выталкивания и извлечения), улучшает возможность работы в автономном режиме и не полагается на одно место для резервного копирования.
В 2010 году автор разработки программного обеспечения Джоэл Спольски охарактеризовал распределенные системы контроля версий как «возможно, самый большой прогресс в технологии разработки программного обеспечения за [последние] десять лет».
Распределенные системы управления версиями (DVCS) используют одноранговый подход к управлению версиями, в отличие от клиент-серверного подхода централизованные системы. Распределенный контроль версий синхронизирует репозитории, передавая исправления от однорангового узла к одноранговому. Не существует единой центральной версии кодовой базы; вместо этого у каждого пользователя есть рабочая копия и полная история изменений.
Преимущества DVCS (по сравнению с централизованными системами) включают:
Недостатки DVCS (по сравнению с централизованными системами) включают:
Некоторые изначально централизованные системы теперь предлагают некоторые распределенные функции. Например, Subversion может выполнять многие операции без сети. Team Foundation Server и Visual Studio Team Services теперь размещают централизованные и распределенные репозитории управления версиями через хостинг Git.
Аналогичным образом, некоторые распределенные системы теперь предлагают функции, которые смягчают проблемы времени оформления заказа и затрат на хранение, такие как Виртуальная файловая система для Git, разработанная Microsoft для работы с очень большими базами кода, которые предоставляет виртуальную файловую систему, которая загружает файлы в локальное хранилище только по мере необходимости.
Распределенная модель обычно лучше подходит для крупных проектов с частично независимыми разработчиками, таких как проект ядра Linux, потому что разработчики могут работать независимо и отправлять свои изменения на слияние (или отклонение). Распределенная модель позволяет гибко применять пользовательские рабочие процессы добавления исходного кода. Рабочий процесс интегратора является наиболее широко используемым. В централизованной модели разработчики должны сериализовать свою работу, чтобы избежать проблем с разными версиями.
У каждого проекта есть центральный репозиторий, который считается официальным репозиторием, которым управляют сопровождающие проекта. Разработчики клонируют этот репозиторий для создания идентичных локальных копий базы кода. Изменения исходного кода в центральном репозитории периодически синхронизируются с локальным репозиторием.
Разработчик создает новую ветку в своем локальном репозитории и изменяет исходный код в этой ветке. После завершения разработки изменение необходимо интегрировать в центральный репозиторий.
Пополнение репозитория исходного кода, использующего распределенную систему контроля версий, обычно осуществляется с помощью запроса на вытягивание, также известного как запрос на слияние . Участник просит, чтобы сопровождающий проекта извлек изменение исходного кода, отсюда и название «запрос на извлечение». Сопровождающий должен объединить пул-реквест, если вклад должен стать частью исходной базы.
Разработчик создает пул-реквест, чтобы уведомить сопровождающих о новом изменении; цепочка комментариев связана с каждым запросом на перенос. Это позволяет целенаправленно обсуждать изменения кода. Отправленные запросы на вытягивание видны всем, у кого есть доступ к репозиторию. Сопровождающие могут принять или отклонить запрос на вытягивание.
После того, как запрос на вытягивание будет рассмотрен и одобрен, он будет добавлен в репозиторий. В зависимости от установленного рабочего процесса, код может потребоваться протестировать перед включением в официальный выпуск. Поэтому в некоторых проектах есть специальная ветка для объединения непроверенных запросов на вытягивание. Другие проекты запускают автоматизированный набор тестов для каждого запроса на вытягивание с использованием инструмента непрерывной интеграции, такого как Travis CI, и рецензент проверяет, имеет ли новый код соответствующее покрытие тестирования.
Первые системы DVCS с открытым исходным кодом включали Arch, Monotone и Darcs. Однако DVCS с открытым исходным кодом никогда не пользовались большой популярностью до выпуска Git и Mercurial.
BitKeeper, которые использовались при разработке ядра Linux с 2002 по 2005. Разработка Git, в настоящее время самой популярной в мире системы контроля версий, была вызвана решением компании, которая заставила BitKeeper отозвать бесплатную лицензию, которую ранее использовали Линус Торвальдс и некоторые другие разработчики ядра Linux. преимущество.
