Распределенные рабочие процессы | Pro Git

В отличии от централизованных систем контроля версий, распределенная природа Git-а позволяет вам быть гораздо более гибким в отношении участия разработчика в работе над проектом. В централизованных системах, каждый разработчик является узлом сети, работающим в более или менее равной степени на центральном хабе. В Git, однако, каждый разработчик потенциально является и узлом и хабом (концентратором) — то есть каждый разработчик может и вносить код в другие репозитории и содержать публичный репозиторий, основываясь на котором могут работать другие разработчики и в который они могут вносить свои изменения. Это открывает широкие возможности по ведению рабочего процесса для вас и и/или для вашей команды, так что я рассмотрю несколько распространенных парадигм, которые используют преимущества такой гибкости. Я рассмотрю сильные стороны и возможные слабые места каждой из моделей; вы можете выбрать одну из них, а можете сочетать и совмещать особенности каждой.

Централизованный рабочий процесс

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

Рисунок 5-1. Централизованный рабочий процесс

Это значит, что если два разработчика выполняют клонирование с хаба и оба делают изменения в проекте, то первый из них, кто выкладывает свои изменения обратно на хаб, сделает это без проблем. Второй разработчик должен взять наработки первого и выполнить слияние до того, как начнет выкладывать свои изменения, так чтобы не перезаписать изменения первого разработчика. Эта концепция также применима в Git как и в Subversion (или любой другой CVCS), и в Git такая модель работает отлично. Если вы имеете небольшую команду или уже комфортно чувствуете себя при применении централизованного рабочего процесса в вашей компании или команде, вы можете запросто продолжить использовать такой рабочий процесс в Git. Просто настройте один репозиторий и дайте каждому в вашей команде право записи (push access); Git не позволить пользователям перезаписывать наработки друг-друга. Если один разработчик выполняет клонирование, делает изменения, а затем пытается выложить эти изменения, в то время как другой разработчик уже успел выложить свои, сервер отклонит изменения этого разработчика. Ему будет сказано, что он пытается выложить изменения, для которых невозможно выполнить fast-forward и что надо сначала извлечь данные с сервера, выполнить слияние, а уже потом выкладывать свои изменения. Этот рабочий процесс привлекателен для большого количества людей, так как это та парадигма, с которой многие знакомы и которая многим понятна.

Рабочий процесс с менеджером по интеграции

Так как Git позволяет вам иметь несколько удаленных репозиториев, существует возможность ведения рабочего процесса, когда каждый разработчик имеет право записи на свой собственный публичный репозиторий и право на чтение для всех остальных. Этот сценарий часто подразумевает существование канонического (основного) репозитория, который представляет “официальный” проект. Чтобы поучаствовать этом проекте, вы создаете вашу собственную публичную копию этого проекта и выкладываете туда свои изменения. Потом вы можете отправить запрос владельцу основного проекта на внесение в него ваших изменений. Он может добавить ваш репозиторий как удаленный, протестировать локально ваши изменения, слить их со своей веткой и затем выложить обратно в публичный репозиторий. Этот процесс работает как описано далее (смотри Рисунок 5-2):

Владелец проекта выкладывает информацию в публичный репозиторий.
Участники проекта клонируют этот репозиторий и делают изменения.
Участники выкладывают изменения в свои собственные публичные репозитории.
Участник проекта отправляет владельцу на e-mail письмо с просьбой включения его изменений.
Владелец проекта добавляет репозиторий участника как удаленный и локально выполняет слияние.
Владелец выкладывает обновленный проект (с включенными изменениями) в основной репозиторий.

Рисунок 5-2. Рабочий процесс с менеджером по интеграции

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

Рабочий процесс с диктатором и помощниками

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

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

Рисунок 5-3. Рабочий процесс сЭто несколько широко применяемых рабочих процессов, которые доступны при работе с такой распределенной системой, как Git, но вы можете увидеть, что возможно множество их вариаций, чтобы удовлетворить требованиям вашего реального рабочего процесса. Теперь, когда вы можете (я надеюсь) определить, какая комбинация рабочих процессов может послужить вам, я рассмотрю некоторые более специфичные примеры выполнения основных действий, являющихся частью разных процессов. благосклонным диктатором

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