Когда над проектом работает команда, очень важно правильно организовать рабочий процесс. Разберем эффективный Git workflow на примере.
Вчера код работал, а сегодня уже нет
Код по ошибке был удален
Внезапно появилась странная ошибка, и никто не знает, откуда она взялась
Попадали хоть раз в одну из этих ситуаций? Если да, то читайте дальше. В этой статье мы познакомимся с самым популярным Git workflow, который позволит максимально увеличить эффективность вашей команды.
Один проект – много разработчиков
Посмотрите на эту диаграмму, она схематично описывает организацию работы:
Сейчас мы разберем ее подробнее.
Сценарий
Представьте, что вы вдруг стали техническим руководителем проекта по созданию нового Facebook. В вашей команде три разработчика:
- стажер Алиса недавно начала изучать программирование;
- Боб работает уже больше года и имеет неплохие навыки;
- и Джон с тремя годами опыта.
И, конечно, вы сами – технический руководитель.
Git workflow
Ветка Master
Master – это всегда актуальная копия существующего кода на продакшене. Никто, включая технического руководителя, не должен вносить изменения прямо в эту ветку, так как это напрямую отразится на работающем продукте.
Весь код фактически пишется в других ветках.
Ветка Release
При старте проекта первым делом создается релизная ветка для него на базе master. Весь код, относящийся к этому проекту, должен находиться здесь. Релизная ветка – это обычная Git-ветка с префиксом release/. Давайте для примера назовем ее release/fb.
Бывает такое, что в рамках одной кодовой базы существует несколько проектов. Для каждого из них создается отдельная релизная ветка, и они развиваются параллельно. Это необходимо для избежания конфликтов между проектами. Например, у нас могла бы быть ветка release/messenger.
Ветка Feature
Для каждого нового компонента или функциональности создается отдельная feature-ветка, которая отличается от обычной только префиксом feature/. Это обеспечивает независимую разработку.
- Вы, как технический руководитель, поручили Алисе сделать страницу авторизации для вашего Facebook. Она создает новую ветку feature/login, в которой будет работать над этой задачей. Feature-ветка обычно ответвляется от релизной.
- Боб получил задание сделать страницу для запросов в друзья. Его ветка feature/friendrequest.
- Джон работает над созданием ленты новостей в ветке feature/newsfeed.
Что ж, все разработчики при деле, каждый – в своей feature-ветке. Вы замечательно организовали свою команду!
Алиса уже закончила свою работу: регистрация готова. Теперь нужно отправить ее код из feature/login в релизную ветку release/fb. Алиса должна сделать pull request.
Pull request
Прежде всего, не следует путать пул-запрос и команду Git pull. Подробнее узнать об этом вы можете здесь.
Разработчик не может напрямую отправлять свои изменения в релизную ветку. Прежде их должен проверить технический руководитель. Для этого и предназначены пул-запросы.
На GitHub Алиса может отправить pull request следующим образом:
Сразу после названия ветки есть кнопка New pull request. Если нажать на нее, откроется новый экран:
- compare – это ветка Алисы feature/login;
- base – релизная ветка release/fb.
Когда Алиса выберет ветки и укажет заголовок и описание для своего запроса, она должна нажать кнопку Create Pull Request. Также нужно указать рецензента, который проверит новый код. Разумеется, здесь должно быть ваше имя, ведь вы технический руководитель проекта.
Когда вы проверите запрос Алисы и сольете feature-ветку с релизной, она будет очень рада.
Конфликты кода
Боб тоже закончил работу и отправил пул-запрос из feature/friendrequest на release/fb.
В релизной ветке уже находится новый код авторизации, который написала Алиса, поэтому возникают конфликты. Решать их должен рецензент запроса, то есть вы.
Пока вы разбирались, Джон тоже дописал свой код. Теперь ему нужно добавить его в релизную ветку, где уже есть новые фичи от Алисы и Боба. Джон – опытный разработчик и умеет предотвращать конфликты. Он берет весь свежий код из release/fb и переносит его в свою рабочую ветку с помощью git pull или git merge. Здесь он разрешает все возникшие конфликты самостоятельно. Теперь в feature/newsfeed содержится самая последняя версия проекта.
Только после этого Джон создает pull request, который вы можете спокойно принять.
Таким образом, конфликты кода может решать рецензент пул-запроса или сам разработчик в feature-ветке.
Снова master
Когда проект завершен, код из релизной ветки сливается с master и развертывается на продакшене. Таким образом, работающий продукт и master-код – это одно и то же.
Поздравляем
Теперь вы знаете, как использовать Git наилучшим образом. Есть и другие очень полезные функции, например, commit amend или rebase. Но понимание Git workflow особенно важно для успешной работы больших проектов. Если вы только начинаете знакомиться с Git, вам будет полезно это простое введение.
Перевод статьи How to use Git efficiently
Комментарии