Введение в распределённый рабочий процесс
В отличие от централизованных систем контроля версий, распределённая природа Git позволяет разработчикам гибко взаимодействовать в рамках проекта. В централизованных системах каждый разработчик — это узел, синхронизирующийся с центральным хабом. В Git же каждый разработчик одновременно является и узлом, и хабом: он может отправлять код в другие репозитории и поддерживать публичный репозиторий, куда другие могут вносить изменения. Это открывает множество вариантов организации рабочего процесса, о которых я расскажу ниже, выделив их сильные и слабые стороны для выбора подходящего подхода или комбинации.
Централизованная работа
В централизованных системах существует одна модель взаимодействия — рабочий процесс с центральным репозиторием, принимающим код, с которым синхронизируются все разработчики как узлы. Если два разработчика клонируют репозиторий и вносят изменения, первый отправляет их без проблем, а второй должен слить изменения первого, чтобы избежать перезаписи. Этот подход работает в Git так же, как и в Subversion.
Если ваша команда уже использует централизованный процесс, переход на Git не требует изменений. Создайте один репозиторий с push-доступом для всех — Git предотвратит перезапись чужих изменений. Например, Алексей отправляет свои изменения на сервер, а Роман, пытаясь сделать то же, получает отказ из-за невозможности быстрой перемотки, пока не сольёт обновления. Этот знакомый процесс подходит как для малых, так и для больших команд, где ветвление Git позволяет сотням разработчиков работать с десятками веток одновременно.
Диспетчер интеграции
Git поддерживает работу с несколькими удалёнными репозиториями, что позволяет каждому разработчику иметь свой публичный репозиторий с правом записи и доступом на чтение ко всем остальным. Канонический репозиторий служит «официальным» проектом. Процесс включает:
- Сопровождающий отправляет изменения в свой публичный репозиторий.
- Участник клонирует его, вносит изменения и отправляет их в свой репозиторий.
- Участник отправляет запрос на слияние сопровождающему.
- Сопровождающий добавляет репозиторий участника как удалённый, тестирует изменения и сливает их в основной репозиторий.
Этот подход популярен на платформах вроде GitHub или GitLab, где можно создать форк. Преимущество — разработчики работают в своём темпе, а сопровождающий интегрирует изменения по своему усмотрению.
Диктатор и помощники
Этот подход подходит для крупных проектов, таких как ядро Linux, с сотнями участников. Помощники (интеграционные менеджеры) управляют частями репозитория, а над ними — диктатор, контролирующий эталонный репозиторий. Процесс:
- Разработчики работают в тематических ветках, перебазированных на master эталонного репозитория.
- Помощники сливают эти ветки в свои master.
- Диктатор сливает мастеры помощников в свой master.
- Диктатор отправляет master в эталонный репозиторий.
Этот метод эффективен для иерархических или масштабных проектов, позволяя лидеру делегировать задачи и собирать код поэтапно.
Шаблоны управления ветками
Мартин Фаулер в своём руководстве «Шаблоны для управления ветками исходного кода» описывает стандартные рабочие процессы Git, включая сравнение высокой и низкой частоты слияний, что полезно для выбора стратегии.
Заключение
Распределённые системы, такие как Git, предлагают разнообразие рабочих процессов — от централизованной модели до сложных иерархий с диктатором и помощниками. Выбор подходящего подхода зависит от размера команды и проекта.
Отзывы