Использование центрального хранилища противоречит цели GIT?

Question

Если вы работаете в корпоративном окружении, в котором много людей работают над определенным приложением, идет ли вразрез с системой распределенной системы контроля версий , имеющей официальный центральный репозиторий?

Иногда мне трудно понять концепцию распределенной системы управления версиями, такой как GIT в корпоративной среде. Если у вас нет центрального репозитория, не будет ли PITA выяснить, у кого есть последняя обновленная версия, у кого есть функция x или исправление ошибки y, которую каждый должен получить, и т. Д., И т. Д.

Это побеждает цель GIT использовать его аналогично SVN с центральным хранилищем, из которого все выталкивают / вытягивают? Каждый раз, когда я думаю об этом, я чувствую, что упускаю суть всего.

Может ли кто-нибудь просветить меня?

Answer 1

Вы, вероятно, думаете по схеме:

Это, вероятно, будет похоже на хаос, исходящий от CVCS. «Нам нужен какой-то порядок», я слышал, вы говорите?

Если у вас не было центрального хранилища, разве это не PITA, чтобы выяснить, у кого есть последняя обновленная версия, у кого есть функция x или исправление ошибки y, которую каждый должен получить, и т. Д., И т. Д. .

Да. В отличие от CVCS На самом деле не существует «последней версии». Если центральное местоположение отсутствует, вы не сразу узнаете, стоит ли искать Сью, Джо или Еву для получения последней версии. Центральное расположение помогает уточнить, что является последним «стабильным» выпуском.

Нечто подобное:

Возможно, также стоит отметить, что может существовать более одного предполагаемого центрального хранилища в зависимости от прав групп людей в организации.

Представьте себе менеджера проекта, который управляет несколькими командами разработчиков, каждая команда может иметь «центральный» репозиторий, к которому они обращаются. Каждую неделю руководитель проекта может извлекать изменения из каждой команды в свой «центральный» репозиторий, объединять их и отправлять обратно в «центральные» репозитории своих команд.

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

-

• Диаграммы и один абзац любезно предоставлены Статья Калида Азада

Answer 2

Не совсем. DCVS просто дает больше свободы в том, как взаимодействовать между разработчиками, не задействуя центральный репозиторий. Официальный репозиторий является только официальным по общему согласию . В Linux также есть центральный репозиторий, из которого создаются «официальные» выпуски ядра, но между центральным, «официальным», репозиторием и клиентскими репозиториями нет физического различия, как в централизованном VCS.

Answer 3

При распределенном управлении исходным кодом центральное «официальное» хранилище создается политикой, а не архитектурой средства контроля версий.

Answer 4

Определенно не победить цель Git.

Преимущество использования Git или любой другой DVCS, даже если существует центральное официальное хранилище, заключается в все же в том, что контроль источника децентрализован. То есть вы можете взять свою копию репозитория, поработать над своим кодом и делать локальный коммит каждые несколько минут, если вам нужно. Вам не нужно беспокоиться о том, что коммиты находятся на незавершенном коде, который нарушает сборку, все это локально. (И очень быстро.)

Затем, когда вся работа завершена, вы можете очистить историю и поместить завершенные изменения в центральное хранилище в однородном, чистом состоянии.

Я не думаю, что вы можете недооценивать преимущества разделения идеи "частных" коммитов и "публичных" толчков. Это позволяет отслеживать изменения, даже если вы единственный, кто извлекает выгоду из такой небольшой степени детализации.

Answer 5

Если вы отметите это Презентация Git , (слайд 475 и далее), модель центрального хранилища прекрасно поддерживается Git.

Вы можете заставить любого желающего git push его разработки сначала сделать git fetch + git merge, а затем нажать.

Это вовсе не противоречит цели Git и гарантирует, что все «синхронизированы» друг с другом.

Разница с "официальным" репозиторием Линуса , упомянутым JesperE , заключается в том, что он управляется другим рабочим процессом, а именно моделью "Диктатор и лейтенанты", где доступ на запись (push) предоставляется только Линус, и чтение дано для всех.

Теперь: "это победит точку DVC"?

Нет, у вас все еще есть распределенные репозитории, по одному для каждого разработчика, и они могут извлекать / объединять свои собственные репозитории в соответствии со своим внутренним рабочим процессом в команде.
Однако, если они хотят внести свой вклад в центральное репо, им необходимо быть в курсе самой последней истории этого репозитория.

Answer 6

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

Я думаю, что с некоторой дисциплиной модель работает очень хорошо. Эта статья хорошо объясняет различные модели, которые вы можете принять

Answer 7

DVCS, такие как Git, не заставляют вас использовать центральный репозиторий. Конечно, можно объявить один репозиторий «центральным», «официальным» или любым другим, и в контексте компании центральный репозиторий имеет некоторый смысл - если не для разработки, то по крайней мере для целей резервного копирования.