Это значит, что если два разработчика выполняют клонирование с хаба, и оба делают изменения в проекте, то первый из них, кто отправит свои изменения обратно на хаб, сделает это без проблем. Второй разработчик должен взять наработки первого и выполнить слияние перед тем, как отправить свои изменения, так чтобы не перезаписать изменения первого разработчика. Этот принцип справедлив для Git точно также, как и для Subversion (или любой другой ЦСУВ), и в Git такая модель работает отлично.
Если у вас небольшая команда или вас полностью устраивает рабочий процесс централизованного типа, применяемый в вашей компании, вы можете просто продолжить использовать такой рабочий процесс и в Git. Просто настройте один репозиторий и дайте каждому в вашей команде права на отправку изменений; Git не позволит пользователям перезаписывать наработки друг-друга. Если какой-то разработчик склонирует репозиторий, сделает в нём изменения, а затем попытается выложить эти изменения, в то время как другой разработчик уже успел отправить свои, сервер отклонит изменения этого разработчика. Ему будет сказано, что он пытается выложить изменения, для которых невозможно выполнить перемотку (fast-forward), и что надо сначала извлечь данные с сервера, выполнить слияние, а уже потом отправлять свои изменения. Такой рабочий процесс привлекателен для большого количества людей, так как это та модель, с которой многие знакомы, и которая многим понятна.
Рабочий процесс с менеджером по интеграции
Так как Git позволяет иметь несколько удалённых репозиториев, существует возможность ведения такого рабочего процесса, при котором каждый разработчик имеет права на запись в свой собственный публичный репозиторий и права на чтение для всех остальных. Этот сценарий часто подразумевает существование канонического репозитория, который представляет собой "официальный" проект. Чтобы принять участие в работе над этим проектом, надо создать свою собственную публичную копию проекта и выложить туда свои изменения. Потом вы можете отправить запрос владельцу основного проекта на внесение в него ваших изменений. Он может добавить ваш репозиторий в качестве удалённого, протестировать локально ваши изменения, слить их со своей веткой и затем отправить обратно в публичный репозиторий. Этот процесс осуществляется следующим образом (смотри Рисунок 5-2):
Владелец проекта выкладывает файлы в публичный репозиторий.
Участники проекта клонируют этот репозиторий и делают изменения.
Участники выкладывают изменения в свои собственные публичные репозитории.
Участник проекта отправляет владельцу письмо с просьбой включения его изменений.
Владелец проекта добавляет репозиторий участника как удалённый и локально выполняет слияние.
Владелец отправляет слитые изменения в основной репозиторий.
Это очень распространённый тип рабочего процесса для сайтов вроде GitHub, где можно легко форкнуть проект и выложить свои изменения на всеобщее обозрение в собственную копию. Одно из главных преимуществ такого подхода — возможность продолжать работать, в то время, как владелец основного репозитория может включить себе ваши изменения, когда ему угодно. Участникам проекта не придётся ждать, пока их изменения не будут включены в проект — каждый может работать в своём собственном ритме.
Рабочий процесс с диктатором и его помощниками
Это одна из разновидностей рабочего процесса с множеством репозиториев. В основном он используется в огромных проектах с сотнями участников; ядро Linux яркий тому пример. Несколько менеджеров по интеграции заведуют разными частями репозитория; этих людей называют помощниками. У всех этих помощников есть только один менеджер по интеграции, которого называют благосклонным диктатором. Репозиторий благосклонного диктатора служит эталонным репозиторием, откуда все участники проекта должны брать изменения. Этот процесс происходит так (смотри Рисунок 5-3):
Обычные разработчики работают над своими тематическими ветками и перемещают свою работу на вершину ветки master. Ветка master — это та ветка, которая находится у диктатора.
Помощники сливают тематические ветки разработчиков в свои ветки master.
Диктатор выполняет слияние веток master своих помощников со своей веткой master.
Диктатор отправляет свою ветку master в эталонный репозиторий, чтобы остальные разработчики могли выполнять перемещение на неё.