Git flow - модель работы с репозиторием

13.03.2014
Share on FacebookShare on TwitterShare on GooglePlusShare on Linkedin
Автор:

В данной статье мы рассмотрим модель работы с ветками Git под названием git-flow. Модель была предложена Винсентом Дриссеном в его статье “A successful Git branching model” и используется в различных вариациях. Общая схема модели выглядит следующим образом:

Рассмотрим схему подробнее.

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

apt-get install git-flow

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

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

git flow init

После этого пользователю предлагается выбрать шаблоны для названия веток:

No branches exist yet. Base branches must be created now
Branch name for production releases: [master]
Branch name for "next release" development: [develop]
How to name your supporting branch prefixes?
Feature branches? [feature/]
Release branches? [release/]
Hotfix branches? [hotfix/]
Support branches? [support/]
Version tag prefix? []

Здесь можно смело использовать значения по умолчанию и просто пройти все пункты, нажимая Enter. Однако, если вы с самого начала собираетесь использовать такие значения, то в команду можно добавить дополнительный ключ:

git flow init -d

В модели git-flow есть две главных ветки (master и develop), а также несколько дополнительных. Рассмотрим каждую из них по отдельности.

1. Master

Здесь находится стабильный рабочий код, который готов к развертыванию на production-сервере. В данной ветке работа не ведется, и она только сливается с Release и Hotfix ветками. Master создается автоматически при создании репозитория.

2.Develop

Здесь находится весь код, который готовится к следующему релизу. Весь функционал, который касается следующих релизов, здесь находиться не должен.

3. Feature

Так называются функциональные ветки, где находится функционал, например, позадачно. Каждая функциональная ветка создается отдельно, и после выполнения задания объединяется только с веткой develop. Данный процесс автоматизирован и может быть выполнен одной командой:

git flow feature start test 

В соответствии с выбранным шаблоном названия будет создана ветка feature/test.

После реализации функционала нужно объединить эту ветку с develop. Это можно сделать очень просто:

git flow feature finish test

Вышеприведенная команда объединит ветку feature/test с develop и после этого удалит ее. Функциональные ветки вообще существуют только локально, их можно также добавить и в отдаленный репозиторий если есть необходимость, чтобы над функционалом работало несколько человек одновременно. Это делается с помощью:

git flow feature publish test

Жизненный цикл функциональной ветки длится только во время реализации задачи, после этого ее можно удалить из удаленного репозитория стандартными git-инструментами.

4. Release

После того, как готовый или почти готовый функционал помещен в ветку develop, можно начинать готовить релиз. Это последняя ветка перед переносом в master. Здесь могут быть сделаны какие-то минимальные изменения в функционале или выполнены фиксы багов. Добавлять в эту ветку новый большой функционал запрещено, а все комиты нужно переносить в ветку develop. После создания ветки релиза версии v.1.0, в ветку develop уже можно заливать изменения, которые будут касаться следующего релиза (версия v.2.0, например).

Начало и окончание работы с веткой релиза происходит по аналогии с функциональными ветвями:

git flow release start v.1.0.
git flow release finish v.1.0.

5. Hotfix

Если в master ветке появился баг, который требует немедленного вмешательства, то для этого есть ветки hotfix. Команды для работы с ветками исправлений аналогичные:

git flow hotfix start
git flow hotfix finish

Данная ветка нужна для того, чтобы команда разработчиков могла продолжать работу над функционалом в ветке develop, в то время как один из программистов исправляет баг в ветке hotfix. После исправления ветка объединяется с master и develop. Хотя есть один нюанс: если на момент исправления ветка develop уже была стабильной и уже есть ветка релиза, то изменения сливаются с release вместо develop.

Git Flow - это модель, которая показывает, как можно проводить разработку в команде, используя возможности Git. Разработчики могут работать над задачами как индивидуально, так и в группах, не мешая друг другу. При этом в течение всего жизненного цикла разработки существуют только две основные ветки: master и develop, поэтому в репозитории поддерживается постоянный порядок, поскольку все другие ветки являются лишь временными. Данная модель проста и понятна, а применение расширения автоматизации, которое было описано в начале статьи, делает ее очень удобной в использовании.

1 vote, Rating: 5
Share on FacebookShare on TwitterShare on GooglePlusShare on Linkedin

Также по теме

1

Изменения в Drupal 8, кроме всего прочего, коснулись процеcса создания собственных виджетов и форматтеров. Новый плагин API значительно упрощает эту процедуру.

2

Продолжая рассмотрение возможностей модуля Panels, в этом блоге речь пойдет о создании собственного контекста с помощью Chaos tool suite.

3

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

4

Модуль Migrate позволяет импортировать содержимое сайта в Drupal из других источников. Узнайте как установить и настроить этот инструмент для корректной работы.

5

В этой статье речь пойдёт о том, как установить ядро Drupal 8 как сабмодуль. Мы не будем рассматривать само понятие сабмодулей, их преимущества/недостатки, а лишь покажем в деталях, как подобную...

Need a quote? Let's discuss the project

Are you looking for someone to help you with your Drupal Web Development needs? Let’s get in touch and discuss the requirements of your project. We would love to hear from you.

Join to peoples who already subscribe