Модель ветвления для Git
Модель ветвления для Git
Для облегчения работы с git создан удобный набор расширений, который находится в свободном доступе. Его можно также установить, введя в терминале следующую команду:
1 |
apt-get install git-flow |
Для начала, нужно создать пустой репозиторий. Это можно сделать с помощью команды:
1 |
git flow init |
После этого пользователю предлагается выбрать шаблоны для названия веток:
1 |
No branches exist yet. Base branches must be created now | ||||||
2 |
Branch name for production releases: [master] |
| |||||
3 |
Branch name for "next release" development: [develop] |
| |||||
4 |
How to name your supporting branch prefixes? |
| |||||
5 |
Feature branches? [feature/] |
| |||||
6 |
Release branches? [release/] |
| |||||
7 |
Hotfix branches? [hotfix/] |
| |||||
8 |
Support branches? [support/] |
| |||||
9 |
Version tag prefix? [] |
|
Можно использовать значения по умолчанию и пройти все пункты, нажимая Enter. Если вы с самого начала хотите использовать такие значения, то в команду можно добавить дополнительный ключ:
1 |
git flow init -d |
В модели git-flow есть две главных ветки (master и develop), а также несколько дополнительных. Рассмотрим каждую из них по отдельности.
1. Master - главная ветвь для релизов.
Здесь находится стабильный рабочий код, который готов к развертыванию. В данной ветке работа не ведется, и она только сливается с Release и Hotfix ветками. Master создается автоматически при создании репозитория.
2. Develop или dev – главная ветвь разработки.
Здесь находится весь код, который готовится к следующему релизу.
3. Feature - ветви с новыми функциями, которые потенциально будут слиты в dev.
Каждая функциональная ветка создается отдельно, и после выполнения задания объединяется только с веткой develop. Данный процесс автоматизирован и может быть выполнен одной командой:
|
git flow feature start test |
Где 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 |
Ветка hotfix нужна для того, чтобы команда разработчиков могла продолжать работу над функционалом в ветке develop, в то время как один из программистов исправляет ошибки в ветке hotfix. После исправления ветка объединяется с master и develop. Существует один нюанс: если на момент исправления ветка develop уже была стабильной и есть ветка релиза, то изменения сливаются с release вместо develop.
1. Git flow - модель работы с репозиторием — Internetdevels официальный блог.html
2. git flow работаем по чистому _ Блог Новикова Богдана.html
3. Удачная модель ветвления для Git _ Хабрахабр.html
4. Шпаргалка по git-flow.htm