Git
Chapters ▾ 2nd Edition

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  2. Лейтенанты сливают изменения из тематических веток разработчиков в свои ветки master.

  3. Диктатор сливает изменения из master веток лейтенантов в свою ветку master.

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

Рабочий процесс с доброжелательным диктатором.
Рисунок 56. Рабочий процесс с доброжелательным диктатором.

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

Заключение

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