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

редактировать

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

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

Содержание

  • 1 Распределенное и централизованное
  • 2 Модель работы
    • 2.1 Центральные репозитории и репозитории филиалов
    • 2.2 Запросы на вытягивание
  • 3 История
  • 4 См. Также
  • 5 Ссылки
  • 6 Внешние ссылки

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

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

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

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

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

  • Начальная проверка репозитория происходит медленнее по сравнению с проверкой в ​​централизованной системе контроля версий, потому что по умолчанию все ветки и история изменений копируются на локальный компьютер.
  • Отсутствие блокировки ng, который является частью наиболее централизованной системы контроля версий и по-прежнему играет важную роль, когда дело доходит до несовместимых двоичных файлов, таких как графические ресурсы или слишком сложные однофайловые двоичные файлы или пакеты XML (например, офисные документы, файлы PowerBI, пакеты бизнес-аналитики SQL Server Data Tools и т. д.).
  • Дополнительное хранилище, необходимое для каждого пользователя, чтобы иметь полную копию полной истории кодовой базы.
  • Повышенное раскрытие кодовая база, поскольку у каждого участника есть локально уязвимая копия.

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

См. также

Ссылки

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

Последняя правка сделана 2021-05-17 09:16:30
Содержание доступно по лицензии CC BY-SA 3.0 (если не указано иное).
Обратная связь: support@alphapedia.ru
Соглашение
О проекте