Git Flow стало проще с этим полным пошаговым руководством

Git Flow исполнилось десять лет, да здравствует Git Flow!

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

Винсент Дриссен представил десять лет назад Git Flow. С тех пор многие разработчики приняли его на вооружение. Настолько массово, что недавно он написал заметку в своем исходном посте. Он счел полезным убедить разработчиков рассматривать этот рабочий процесс только в том случае, если вам приходится иметь дело с несколькими версиями в производственной среде.

Если вы подходите к этой категории, я по-прежнему считаю Git Flow самым надежным рабочим процессом.

Итак, чтобы отпраздновать десятилетнюю годовщину компании, я посвящу эту статью этому рабочему процессу. Я объясню как можно проще, как уважать его философию.

Основные отрасли

Когда вы создаете репозиторий Git, у него есть ветка master. Это твоя самая чувствительная ветвь. Это моментальный снимок того, что вы поставляете в производство.

Для перехода между двумя выпусками необходимо создать ветку develop. Вот куда вы выльете всю свою текущую работу. Вы никогда не должны напрямую сливаться с master.

Итак, для начала создайте ветку develop и переключитесь на нее. Давайте зафиксируем один раз для иллюстрации:

$ git checkout -b develop
$ git commit -am "First commit on develop"
$ git push -u origin develop

Параметр -u при отправке требуется только при первом отправке ветки в удаленный репозиторий.

Приготовьте свой следующий выпуск

В течение жизненного цикла проекта вы будете разрабатывать функции для улучшения продукта. Каждый раз при запуске создавайте ветку с префиксом feature/ из develop

$ git checkout develop
$ git checkout -b feature/my_awesome_feature

Вы хотите зафиксировать свою работу и отправить ее в удаленную ветку.

$ git commit -am "My awesome commit message"
$ git push -u origin feature/my_awesome_branch

Когда вы закончите работу над функцией, создайте Pull Request на GitHub с таргетингом на develop. Убедитесь, что ваша ветка объединяема. Если нет, я рекомендую вам переустановить свою ветку на develop. Это не так сложно, как говорят некоторые, просто выполните следующие действия, описанные в Не волнуйтесь с Git Rebase.

Наконец, объедините свою ветку, когда и ваши товарищи по команде, и ваш CI позволяют это.

Если вы не используете интерфейс GitHub для объединения веток, вы всегда можете сделать это из интерфейса командной строки.

$ git checkout develop
$ git merge --no-ff origin feature/my_awesome_branch

По умолчанию GitHub выполняет merge --no-ff. См. Документацию для получения дополнительной информации.

Обновите удаленную ветку develop и выполните некоторую очистку

$ git push origin develop
$ git branch -D feature/my_awesome_branch 
$ git push -d origin feature/my_awesome_branch

Последняя строка является необязательной, если вы слились из запроса на слияние, так как вы можете удалить оттуда удаленную ветку.

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

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

Подготовьте свой релиз

Готовитесь выпустить новую версию? Создайте release ветку из develop, так как это ваша самая последняя ветка. Назовите его по названию версии - скажем, 2.0.0.

Предпочитайте наименование с шаблоном MAJOR.MINOR.PATCH. Позже мы увидим почему.

Вот ветка, которую вы создадите:

$ git checkout develop
$ git checkout -b release/v2.0.0

Не забудьте добавить свою версию в код и зафиксировать это изменение:

$ git commit -am "Bump version to 2.0.0"

Обратите внимание, что ветвь release должна содержать только bugfix веток. Вы не хотите предоставлять новую функцию, пока вы собираетесь выпустить новую версию.

С объединенной веткой bugfix на release у вас должно получиться следующее дерево:

Завершите свой выпуск

Как только вы отправите выпуск своим пользователям, вы можете объединить свою ветку release с master. Либо создайте запрос Pull, ориентированный на master, либо сделайте это через интерфейс командной строки.

$ git checkout master
$ git merge --no-ff origin release/v2.0.0

Затем отметьте это тегом v2.0.0 на master.

$ git tag v2.0.0
$ git push --tags

Теперь, прежде чем удалять ветку release, вы должны объединить все исправленные вами ошибки в develop. Во-первых, объедините develop с release, чтобы разрешить потенциальные конфликты.

$ git checkout release/v2.0.0
$ git merge --no-ff origin develop

Как только ваши конфликты будут разрешены, вы можете открыть запрос на слияние, чтобы объединить release в develop.

В официальном руководстве Git Flow обратное слияние выполняется непосредственно из develop. Я бы рекомендовал выполнить дополнительные шаги по двум причинам:

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

Наконец, сделайте уборку.

$ git branch -D release/v2.0.0
$ git push -d origin release/v2.0.0

Теперь, когда вы развернули свой выпуск, вы можете продолжить работу со своим продуктом и подготовиться к следующему выпуску.

Исправьте свой релиз

Давайте посмотрим правде в глаза; ваше приложение будет страдать от ошибок в производстве. Иногда некоторые из них слишком критичны, чтобы ждать следующего выпуска.

Вам нужно будет быстро отреагировать и выпустить неожиданный выпуск, который устранит проблему. Создайте ветку hotfix из master. Назовем его 2.0.1, используя номер ПАТЧА, который я упомянул выше.

После этого вы сделаете то же самое, что и для ветки release:

1. Объединить hotfix в master
2. Отметьте свой hotfix
3. Объединить develop в hotfix
4. Устранение потенциальных конфликтов на hotfix
5. Объединить hotfix в develop
6. Удалить hotfix

С помощью этих шагов у вас есть полное дерево, которое вы могли бы получить:

Мысли о Git Flow

Git Flow обеспечивает проверенный на практике рабочий процесс. Если вы будете следовать этим принципам, вы будете работать быстро и без препятствий.

Спасибо за чтение и поздравляем Git Flow!