Организация рабочих процессов#
Централизованная модель#
Самый очевидный и распространенный способ организации взаимодействия – это централизованная модель. Рабочий процесс в ней организован вокруг одного публичного хранилища. В этой модели управление разработкой берет менеджер проекта. В его обязанности входит планирование, распределение задач по разработчикам, контроль за исполнением планов. Участники проекта знакомы друг с другом и доверяют друг другу. В этой модели взаимодействия каждый разработчик обладает равными правами доступа. Она актуальна для небольших команд с небольшим количеством участников. С течением времени команда разрастается. Чтобы защититься от непреднамеренных внесений нерабочего кода придерживаются следующих правил, которые дополнительно проверяют изменения:
опытный разработчик рецензирует код;
тестировщик прогоняет новую версию программы через тесты;
ответственный за модуль разработчик консультирует тех, кто вносит изменения в этот модуль;
Изменения аккумулируются в тематической ветке и без опасений выкладываются в удаленное хранилище. Когда работа подойдет к своему логическому завершению, изменения интегрируются в основную ветку. Как видно, доступ на запись в хранилище имеют все разработчики, а защита от ошибочных действий оформляется в виде организационных мероприятий.
Модель с интеграционным менеджером#
Централизованная модель взаимодействия не подходит для работы с открытым ПО, где разработчики не знают друг друга. В этом случае правом на запись в хранилище обладает только один человек. Его работа состоит в сопровождении проекта. Он принимает изменения от окружающих, оценивает их и вносит в хранилище. Здесь появляются две роли:
автор – лицо, оформивший изменения;
коммитер – лицо, внесший изменения в хранилище.
Коммитера называют интеграционным менеджером, так как его работа сводится к принятии от других изменений в проект. Какие способы использует интеграционный менеджер, чтобы получать/забирать изменения от сторонних разработчиков? Это:
применение патчей;
интеграция изменений из веток удаленных хранилищ.
Патч – это текстовый файл с описанием коммита.
Команда git format-patch создает патч в формате mailbox, который готов для отправки по почте.
Команда git format-patch -1 HEAD в текущем каталоге создает файл с патчем из одного коммита, на который указывает HEAD.
Получившийся файл (скажем, 0001-Add-arguments-of-main-function.patch) можно применить в другом локальном хранилище командой
git am 0001-Add-arguments-of-main-function.patch
Второй способ приема изменений от разработчиков – это интеграция изменений из веток удаленных хранилищ. В этом случае разработчик, создает копию удаленного хранилища, которым уже имеет полное право распроряжаться по своему желанию. В разработке открытого ПО лицензия позволяет делать это. Далее, он вносит изменения в свое хранилище. После завершения работы он обращается к интеграционному менеджеру с просьбой влить его изменения в официальное хранилище проекта. Эта просьбу называют “pull request” или “запрос на слияние”. Если у интеграционного менеджера нет замечаний по коммитам и работа соответствует его ожиданиям, он забирает изменения из удаленного хранилища в свое локальное хранилище, сливает их и отправляет в официальное хранилище.
Модель с диктатором и помощниками#
Если открытая программа пользуется популярностью, и желающих вносить в нее изменения много, то интеграционный менеджер не будет справляться со своими обязанностями. В этом случае он призывает к себе нескольких помощников. Каждый помощник ответственен за конкретный модуль и принимает изменения только по нему. Подготовленные изменения они передают сопровождающему проекта, который уже их отправляет в официальное хранилище. Сопровождающего проекта называют диктатором. В результате получившаяся модель взаимодействия называется “моделью с диктатором и помощниками”.
