- Централизованный рабочий процесс
- Рабочий процесс с менеджером
- Рабочий процесс с менеджером и его помощниками
- Шаблоны для управления ветками исходного кода
- Заключение
В отличие от централизованных систем контроля версий, распределенная природа Git позволяет вам более гибко взаимодействовать при работе над общим проектом.
В централизованных системах все разработчики являются узлами, более одинаково или менее одинаково работающими с центральным хабом. Однако в Git каждый разработчик потенциально является и узлом, и хабом. То есть каждый разработчик может как вносить код в другие репозитории, так и содержать публичный репозиторий, на основе которого работают другие разработчики, и в который они вносят свои изменения. Это дает вашей команде возможность использовать любой из множества различных способов осуществления рабочего процесса в ваших проектах, поэтому вы рассмотрите несколько распространенных подходов, использующих преимущества Git. Рассмотрите сильные стороны и возможные недостатки каждого подхода. Сможете выбрать для себя один из них, или сможете совместить особенности сразу нескольких подходов.
Централизованная работа
В централизованных системах существует, как правило, одна модель взаимодействия, это централизованный рабочий процесс. Один центральный хаб, или репозиторий, может принимать код, а все остальные синхронизируют свою работу с ним. Некоторое количество разработчиков являются узлами (клиентами этого хаба), и синхронизируются с ним.
Это значит, что если два разработчика склонируют репозиторий и оба делают изменения в проекте, то первый из них, кто отправит свои изменения обратно в репозиторий, сделает это без проблем. Второй разработчик должен взять наработки первого и выполнить слияние перед тем, как отправить свои изменения, так, чтобы не перезаписать изменения первого разработчика. Этот принцип справедлив для Git точно так же, как и для Subversion (или любой другой централизованной системы контроля версий), и в Git такая модель работает отлично.
Если у вас небольшая команда или если вас полностью устраивает централизованный рабочий процесс, применяемый в вашей компании, вы можете просто продолжить использовать такой рабочий процесс и в Git. Просто настройте один репозиторий и дайте каждому в вашей команде права на отправку изменений. Git не позволит пользователям перезаписывать наработки друг друга.
Например, Андрей и Василий начинают работать одновременно. Василий создает свои изменения и отправляет их на сервер. Затем Андрей пытается отправить свои изменения, но сервер отвергает их. Андрею говорят, что он пытается отправить изменения, для которых невозможно выполнить перемотку вперед. Поэтому, прежде чем их отправить, он должен получить изменения с сервера и влить их в свои изменения. Такой рабочий процесс привлекателен для большого количества людей, так как это та модель, с которой многие знакомы и которая многим понятна.
Такой рабочий процесс применим не только для маленьких команд разработчиков. Благодаря модели ветвления, существующей в Git, сотни разработчиков могут успешно работать над одним проектом, используя множество веток одновременно.
Рабочий процесс с менеджером
Так как Git позволяет иметь несколько удаленных репозиториев, можно работать так, чтобы каждый разработчик имел права на запись в свой собственный публичный репозиторий, и права на чтение для всех остальных репозиториев. Этот сценарий часто подразумевает существование основного репозитория, который представляет собой «официальный» проект.
Чтобы принять участие в работе над таким проектом, вы должны создать свою собственную публичную копию основного репозитория и выложить туда свои изменения. Потом вы можете отправить запрос менеджеру на то, чтобы он внес ваши изменения в основной репозиторий. Менеджер может добавить ваш публичный репозиторий себе в качестве удаленного, протестировать локально ваши изменения, влить их в свою ветку, и затем отправить в основной репозиторий.
- Менеджер проекта отправляет файлы в основной репозиторий;
- Разработчики клонируют этот репозиторий и делают свои изменения;
- Разработчики отправляют изменения в свои публичные репозитории;
- Разработчики отправляют менеджеру письмо с просьбой внести их изменения в проект;
- Менеджер добавляет публичные репозитории разработчиков как удаленные и локально выполняет слияние;
- Менеджер отправляет слитые изменения в основной репозиторий.
Это очень распространенный тип рабочего процесса для сайтов вроде GitHub или GitLab, где можно легко сделать копию проекта (fork), и отправить свои изменения в эту копию на всеобщее обозрение. Одно из главных преимуществ такого подхода это ваша возможность, как разработчика, продолжать работать, в то время как менеджер может получить себе ваши изменения, когда ему угодно. Разработчикам не нужно ждать включения своих изменений в проект, каждый может работать в своем собственном ритме.
Рабочий процесс с менеджером и его помощниками
Это одна из разновидностей рабочего процесса с множеством репозиториев. В основном он используется в огромных проектах с сотнями участников. Ядро Linux яркий тому пример.
Несколько помощников заведуют разными частями репозитория. Над всеми этими помощниками есть один менеджер. Менеджер отправляет изменения в основной репозиторий, из которого все разработчики должны получать изменения и сливать их со своими наработками.
- Разработчики работают над своими тематическими ветками и перебазируют свою работу на вершину ветки master. Ветка master это та ветка основного репозитория, в которую отправляет изменения менеджер;
- Помощники сливают тематические ветки разработчиков в свои ветки master.
- Менеджер выполняет слияние веток master своих помощников со своей веткой master.
- В итоге менеджер отправляет свою ветку master в основной репозиторий, чтобы остальные разработчики могли перебазироваться на нее.
Этот тип рабочего процесса не является распространенным, но он может быть полезен в очень больших проектах или в сильно иерархическом окружении. Он позволяет менеджеру передать большинство работы помощникам, а самому собирать только большие порции кода от нескольких помощников перед тем, как объединить их.
Шаблоны для управления ветками исходного кода
Мартин Фаулер сделал руководство «Шаблоны для управления ветками исходного кода». Это руководство охватывает все стандартные рабочие процессы Git и объясняет, как и когда их использовать. Также есть раздел, в котором сравнивается высокая и низкая частота слияния.
Заключение
Вы рассмотрели несколько широко используемых рабочих процессов, применимых в распределенных системах вроде Git. Но, как видите, возможны различные вариации для подгонки под ваш конкретный тип рабочего процесса. Теперь, когда вы в состоянии определить, какая комбинация рабочих процессов сработает для вас лучше, мы рассмотрим несколько частных примеров. В следующем разделе вы узнаете о нескольких распространенных способах внесения своих изменений в общий проект.
По материалам книги Pro Git (авторы Scott Chacon и Ben Straub, издательство Apress). Книга распространяется по лицензии Creative Commons Attribution Non Commercial Share Alike 3.0 license.