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

Distributed version control

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

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

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

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

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

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

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

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

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

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

Модель работы

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

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

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

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

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

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

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

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

История

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

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

Смотрите также

Рекомендации

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

внешняя ссылка