Как работает децентрализованное поведение распределенных систем контроля версий? - PullRequest
3 голосов
/ 05 февраля 2009

Интересно, как работает децентрализованная DVCS? Если нет центрального сервера, как может машина разработчика знать и синхронизировать репозиторий с репозиториями других машин разработчика. А как сливаются изменения? Мне кажется, что отсутствие центрального сервера может привести к тому, что каждый репозиторий будет иметь разные номера ревизий. И как обрабатываются разрешения конфликтов?

Ответы [ 2 ]

2 голосов
/ 05 февраля 2009

Я неравнодушен к Git, но я верю, что теория применима к большинству других систем ...

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

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

На практике разработчик фиксирует свою работу в своей локальной копии, и когда приходит время поделиться ею с другими, он делает это тремя способами:

  • Попросите другого разработчика извлечь изменения непосредственно из них
  • Вставить прямо в копию другого разработчика
  • Перенесите изменения в центральное место, откуда другие могут вытащить

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

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

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

Большинство слияний происходит автоматически, но когда возникает конфликт, разрешить его довольно просто. Приятно то, что вы не получите шар конфликтов, охватывающий несколько коммитов: его гораздо легче разрешить, потому что он делает паузу в середине истории и позволяет разбираться с ним небольшими логическими кусками.

2 голосов
/ 05 февраля 2009

Презентация Скотта Чакона от RailsConf в прошлом году была потрясающей. Одна из лучших запланированных и информационных бесед, которые я когда-либо видел. Я передам ему (в частности, по вашему вопросу, часть удаленного рабочего процесса начинается примерно через 18 минут):

RailsConf Git Talk

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