Git
Chapters ▾ 2nd Edition

5.1 Распределённый Git - Распределённый рабочий процесс

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

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

Распределённый рабочий процесс

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

Централизованная работа

В централизованных системах, как правило, присутствует только одна модель взаимодействия — централизованный рабочий процесс. Центральный хаб или репозиторий может принимать код, а все остальные синхронизируют свою работу с ним. Все разработчики являются узлами (пользователями хаба) и синхронизируются только с ним.

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

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

Если в вашей организации или команде уже используется централизованный рабочий процесс, то вам ничего не нужно менять для работы с Git. Достаточно создать один репозиторий и предоставить каждому члену команды push-доступ; Git не позволит перезаписать изменения, сделанные другими.

Предположим, Джон и Джессика начинают работать над проектом одновременно. Джон вносит изменения и отправляет их на сервер. Затем Джессика пытается отправить свои изменения, но сервер их отклоняет. Ей говорят, что она пытается отправить изменения, для которых невозможно выполнить быструю перемотку и она не сможет это сделать пока не получит все новые для неё изменения и не сольёт их. Такой рабочий процесс привлекает большинство людей, так как реализует парадигму, с которой они уже знакомы.

Такой подход применим не только к небольшим командам. Используя модель ветвления Git, сотни разработчиков могут одновременно работать над одним проектом, используя при этом десятки веток.

Диспетчер интеграции

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

  1. Сопровождающий проекта отправляет изменения в свой публичный репозиторий.

  2. Участник клонирует этот репозиторий и вносит изменения.

  3. Участник отправляет свои изменения в свой публичный репозиторий.

  4. Участник отправляет письмо сопровождающему с запросом на слияние изменений.

  5. Сопровождающий добавляет репозиторий участника как удалённый и сливает изменения локально.

  6. Сопровождающий отправляет слитые изменения в основной репозиторий.

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

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

Диктатор и помощники

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

  1. Обычные разработчики работают в своих тематических ветках и перебазируют свою работу относительно ветки master. Ветка master — это ветка эталонного репозитория в которую имеет доступ только диктатор.

  2. Помощники сливают тематические ветки разработчиков в свои ветки master.

  3. Диктатор сливает ветки master помощников в свою ветку master.

  4. Наконец, диктатор отправляет свою ветку master в эталонный репозиторий, чтобы все остальные могли перебазировать свою работу на основании неё.

Рабочий процесс с великодушным диктатором
Рисунок 55. Рабочий процесс с великодушным диктатором

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

Шаблоны для управления ветками исходного кода

Примечание

Мартин Фаулер сделал руководство «Шаблоны для управления ветками исходного кода». Это руководство охватывает все стандартные рабочие процессы Git и объясняет, как и когда их использовать. Также есть раздел, в котором сравнивается высокая и низкая частота слияния.

https://martinfowler.com/articles/branching-patterns.html

Заключение

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

scroll-to-top