Из Википедии, свободной энциклопедии
  (Перенаправлено из распределенного контроля версий )
Перейти к навигации Перейти к поиску

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

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

Распределенное и централизованное [ править ]

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

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

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

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

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

Некоторые изначально централизованные системы теперь предлагают некоторые распределенные функции. Например, Subversion может выполнять множество операций без сети. [8] Team Foundation Server и Visual Studio Team Services теперь размещают централизованные и распределенные репозитории управления версиями через хостинг Git.

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

Модель работы [ править ]

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

Центральные и отраслевые репозитории [ править ]

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

Разработчик создает новую ветку в своем локальном репозитории и изменяет исходный код в этой ветке. После завершения разработки изменение необходимо интегрировать в центральный репозиторий.

Запросы на вытягивание [ править ]

Пополнение репозитория исходного кода, использующего распределенную систему контроля версий, обычно осуществляется с помощью запроса на вытягивание , также известного как запрос на слияние . [10] Участник требует, чтобы сопровождающий проекта извлек изменение исходного кода, отсюда и название «запрос на извлечение». Сопровождающий должен объединить пулреквест, если вклад должен стать частью исходной базы. [11]

Разработчик создает запрос на перенос, чтобы уведомить разработчиков о новом изменении; цепочка комментариев связана с каждым запросом на вытягивание. Это позволяет целенаправленно обсуждать изменения кода . Отправленные запросы на вытягивание видны всем, у кого есть доступ к репозиторию. Сопровождающие могут принять или отклонить пул-реквест. [12]

После того, как запрос на вытягивание будет рассмотрен и одобрен, он будет добавлен в репозиторий. В зависимости от установленного рабочего процесса, код может потребоваться протестировать перед включением в официальный выпуск. Поэтому в некоторых проектах есть специальная ветка для объединения непроверенных запросов на вытягивание. [11] [13] В других проектах запускается автоматизированный набор тестов для каждого запроса на вытягивание с использованием инструмента непрерывной интеграции , такого как Travis CI , и рецензент проверяет, имеет ли новый код соответствующее покрытие тестирования.

История [ править ]

Первые системы DVCS с открытым исходным кодом включали Arch , Monotone и Darcs . Однако DVCS с открытым исходным кодом никогда не пользовались большой популярностью до выпуска Git и Mercurial .

BitKeeper использовался при разработке ядра Linux с 2002 по 2005 год. [14] Разработка Git , ныне самой популярной в мире системы контроля версий [5], была вызвана решением компании, которая заставила BitKeeper отказаться от бесплатного использования. лицензия, которой ранее воспользовались Линус Торвальдс и некоторые другие разработчики ядра Linux. [14]

См. Также [ править ]

  • Контроль версий
  • Список программного обеспечения для контроля версий
  • Сравнение программного обеспечения для контроля версий
  • Категория: Программное обеспечение с использованием распределенного контроля версий
  • Клон репозитория
  • Git , DVCS с открытым исходным кодом, разработанная для разработки ядра Linux.
  • Mercurial , кроссплатформенная система, похожая на Git
  • Fossil , распределенная система контроля версий, система отслеживания ошибок и вики-программы
  • BitKeeper
  • GNU Bazaar
  • Система одновременных версий , предшественник распределенных систем контроля версий
  • TortoiseHg , графический интерфейс для Mercurial
  • Code Co-op , одноранговая система контроля версий

Ссылки [ править ]

  1. ^ a b Чакон, Скотт; Штрауб, Бен (2014). «Начало работы - о контроле версий» . Pro Git (2-е изд.). Апресс. Глава 1.1 . Дата обращения 4 июня 2019 .
  2. ^ a b Спольски, Джоэл (17 марта 2010 г.). «Распределенный контроль версий никуда не денется, детка» . Джоэл о программном обеспечении . Дата обращения 4 июня 2019 .
  3. ^ «Введение в распределенный контроль версий (проиллюстрировано)» . www.betterexplained.com . Проверено 7 января 2018 .
  4. ^ «Что такое Git? - Изучите средство управления распределенными версиями» . www.edureka.co . Проверено 7 января 2018 .
  5. ^ a b «Популярность систем контроля версий в 2016 году» . www.rhodecode.com . Проверено 7 января 2018 .
  6. ^ а б О'Салливан, Брайан. «Распределенный контроль версий с Mercurial» . Проверено 13 июля 2007 года .
  7. ^ «Что такое контроль версий: централизованный или DVCS» . www.atlassian.com . Проверено 7 января 2018 .
  8. ^ OSDir.com. "Subversion для пользователей CVS :: OSDir.com :: Открытый исходный код, новости и программное обеспечение Linux" . OSDir.com. Архивировано из оригинала на 2016-08-23 . Проверено 22 июля 2013 .
  9. ^ Джонатан Аллен (2017-02-08). «Как Microsoft решила проблему Git с большими репозиториями» . Проверено 6 августа 2019 .
  10. ^ Sijbrandij, Sytse (29 сентября 2014). «GitLab Flow» . GitLab . Проверено 4 августа 2018 .
  11. ^ a b Джонсон, Марк (8 ноября 2013 г.). "Что такое пул-реквест?" . Oaawatch . Проверено 27 марта 2016 года .
  12. ^ "Использование запросов на вытягивание" . GitHub . Проверено 27 марта 2016 года .
  13. ^ «Создание запроса на извлечение» . Atlassian . Проверено 27 марта 2016 года .
  14. ^ а б Макаллистер, Нил. "Ошибка BitKeeper Линуса Торвальдса" . InfoWorld . Проверено 19 марта 2017 .

Внешние ссылки [ править ]

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