Commit dde16f4a authored by Николай Михайличенко's avatar Николай Михайличенко
Browse files

Первоначальный коммит

parents
# GitFlow
Модель ветвления в проекте
![Образец ветвления](img/title.png)
## Главные ветви
Репозиторий содержит две главные ветви, существующие всё время:
- master
- develop
В *master* исходный код находится в состоянии *production-ready* в любой произвольный момент времени.
Ветвь *develop* считается *основной ветвью разработки*. Хранящийся в ней код в любой момент времени должен содержать самые последние изданные изменения, необходимые для следующего релиза.
## Вспомогательные ветви
Вспомогательные ветви используются для распараллеливания разработки между членами команды. В отличие от главных ветвей, эти ветви всегда имеют ограниченный срок жизни. Каждая из них в конечном итоге рано или поздно удаляется.
- Ветви функциональностей (Feature branches)
- Ветви релизов (Release branches)
- Ветви исправлений (Hotfix branches)
## Ветви функциональностей (feature branches)
Порождаются от: develop
Вливаются в: develop
Соглашение о наименовании: всё, за исключением master, develop, release-* или hotfix-*
При начале работы над новой функциональностью делается ответвление от ветви разработки (develop).
Когда работа в ветви завершена, последняя вливается обратно в главную ветвь разработки (что означает, что функциональность будет добавлена в грядущий релиз) или же удаляется (в случае неудачного эксперимента).
### Создание ветви функциональности (feature branch)
При начале работы над новой функциональностью делается ответвление от ветви разработки (develop)
```bash
git checkout -b myfeature develop
```
### Добавление завершённой функциональности в develop
Завершённая функциональность (фича) вливается обратно в ветвь разработки (develop) и попадает в следующий релиз.
```bash
git checkout develop
git merge --no-ff myfeature
git branch -d myfeature
git push origin develop
```
> Флаг --no-ff вынуждает Git всегда создавать новый объект коммита при слиянии, даже если слияние может быть осуществлено алгоритмом fast-forward. Это позволяет не терять информацию о том, что ветка существовала, и группирует вместе все внесённые изменения
![Ветвь функциональностей](img/feature_branches.png)
## Ветви релизов (release branches)
Порождаются от: develop
Вливаются в: develop и master
Соглашение о наименовании: release-*
Ветви релизов (release branches) используются для подготовки к выпуску новых версий продукта.
Новую ветку релиза (release branch) надо порождать в тот момент, когда состояние ветви разработки полностью или почти полностью соответствует требованиям, соответствующим новому релизу.
Очередной релиз получает свой номер версии только в тот момент, когда для него создаётся новая ветвь, но ни в коем случае не раньше.
### Создание ветви релиза (release branch)
Ветвь релиза создаётся из ветви разработки (develop).
```bash
git checkout -b release-1.2 develop
./bump-version.sh 1.2
git commit -a -m "Bumped version number to 1.2"
```
Эта новая ветвь может существовать ещё некоторое время, до тех пор, пока новый релиз окончательно не будет готов к выпуску. В течение этого времени к этой ветви (а не к develop) могут быть добавлены исправления найденных багов. Но добавление крупных новых изменений в эту ветвь строго запрещено. Они всегда должны вливаться в ветвь разработки (develop) и ждать следующего большого релиза.
### Закрытие ветви релиза
Когда ветвь релиза (release branch) окончательно готова для выпуска, нужно выполнить следующее:
- ветвь релиза вливается в ветвь master
- коммит в master должен быть помечен тегом
- ветвь релиза вливается в ветвь develop
```bash
git checkout master
git merge --no-ff release-1.2
git tag -a 1.2
git checkout develop
git merge --no-ff release-1.2
git branch -d release-1.2
```
## Ветви исправлений (hotfix branches)
Порождаются от: master
Вливаются в: develop и master
Соглашение о наименовании: hotfix-*
Ветви для исправлений (hotfix branches) используются для подготовки незапланированных выпусков продукта.
Они порождаются необходимостью немедленно исправить нежелательное поведение производственной версии продукта. Когда в производственной версии находится баг, требующий немедленного исправления, из соответствующего данной версии тега главной ветви (master) порождается новая ветвь для работы над исправлением.
### Создание ветви исправлений (hotfix branch)
Ветви исправлений (hotfix branches) создаются из главной (master) ветви
```bash
git checkout -b hotfix-1.2.1 master
./bump-version.sh 1.2.1
git commit -a -m "Bumped version number to 1.2.1"
...
git commit -m "Fixed severe production problem"
```
### Закрытие ветви исправлений
Когда баг исправлен, изменения надо влить обратно в главную ветвь (master), а также в ветвь разработки (develop), чтобы гарантировать, что это исправление окажется и в следующем релизе.
> У этого правила есть одно исключение: если в данный момент существует ветвь релиза (release branch), то ветвь исправления (hotfix branch) должна вливаться в неё, а не в ветвь разработки (develop)
```bash
git checkout master
git merge --no-ff hotfix-1.2.1
git tag -a 1.2.1
git checkout develop
git merge --no-ff hotfix-1.2.1
git branch -d hotfix-1.2.1
```
![Ветви исправлений](img/hot_fixes.png)
## Источники
[A successful Git branching model](http://nvie.com/posts/a-successful-git-branching-model/)
[Удачная модель ветвления](https://habrahabr.ru/post/106912/) [перевод первой статьи]
Markdown is supported
0% or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment