Почему git называется распределенной системой контроля версий?

Question

Кажется, что после фиксации кода в локальном репозитории каждый программист выполнит команду.

git push origin master

для отправки локального файла на определенный удаленный сервер. Это не отличается от модели клиент / сервер, за исключением локальной копии, так почему она называется «распределенной»?

Answer 1

Краткий ответ

Он не отличается от модели клиент / сервер, за исключением локальной копии, так почему она называется «распределенной»?

ВНа диаграмме ниже Алиса и Дэвид может взаимодействовать, поскольку система распределена .

Распределенная система контроля версий

Обратите внимание, как, скажем, Алиса и Дэвид могут взаимодействовать, поскольку каждый из них может выступать в качестве сервера.

Центральный контроль версий

Здесь команда разработчиков взаимодействует только с главным сервером.

---

Длинный ответ

ТрадиционноГоворя об исходных системах контроля, они были разработаны как сервер-клиент, если говорить в произвольной форме.Таким образом, хранилище расположено в центре .

С git и Mercurial система разработана так, чтобы все пользователи были на равных. Каждый имеет полный репозиторий с собой.Таким образом, управление и репозиторий распределяются среди пользователей по 1047 *.

Answer 2

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

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

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

(Источник: Прагматическое управление версиями с использованием Git от Travis Swicegood)

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

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

. В Википедии есть еще немного информации: Распределенный контроль версий

Я также настоятельно рекомендую вышеупомянутую книгу Pragmatic Programmers по Git.

Answer 3

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

Answer 4

Потому что ваш клон может быть чужим хозяином, и вы можете подтолкнуть своего клона к любому другому хранилищу. Нет необходимости в понятии одного «истинного» мастера; Вы можете запустить его как распределенную сетку хранилищ.

Answer 5

Проверьте определение распределенной системы и сравните это с тем, что Git делает / позволяет делать ... Я думаю, что это соответствует ... клиент-серверный подход необходим по определению один " окончательная / справочная копия ", что не относится к Git и аналогичным ...