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

Merge branch 'develop' into 'master'

Develop

See merge request !2
parents 396d29e6 1937de49
# GitFlow
Модель ветвления в проекте
Модель ветвления в проекте при использовании Gitlab.
Версия 1.0
Версия 1.1
![Образец ветвления](img/title.png)
......@@ -19,6 +19,8 @@
Ветвь *develop* считается *основной ветвью разработки*. Хранящийся в ней код в любой момент времени должен содержать самые последние изданные изменения, необходимые для следующего релиза.
В gitlab эти ветви помечаются как *protected*. Недопускается коммитить в главные ветви, разрешено только вливать вспомогательные ветви.
## Вспомогательные ветви
Вспомогательные ветви используются для распараллеливания разработки между членами команды. В отличие от главных ветвей, эти ветви всегда имеют ограниченный срок жизни. Каждая из них в конечном итоге рано или поздно удаляется.
......@@ -32,7 +34,9 @@
## Ветви функциональностей (feature branches)
Порождаются от: develop
Вливаются в: develop
Соглашение о наименовании: всё, за исключением master, develop, release-* или hotfix-*
При начале работы над новой функциональностью делается ответвление от ветви разработки (develop).
......@@ -41,24 +45,47 @@
### Создание ветви функциональности (feature branch)
При начале работы над новой функциональностью делается ответвление от ветви разработки (develop)
При начале работы над новой функциональностью на машине разработчика делается обновление ветки разработки (develop) и ответвление от нее.
```bash
git checkout -b myfeature develop
git checkout develop
git pull
git checkout -b myfeature
```
### Добавление завершённой функциональности в develop
Завершённая функциональность (фича) вливается обратно в ветвь разработки (develop) и попадает в следующий релиз.
Общий порядок сливания ветви функциональности и основной ветви разработки:
1) Тестирование функциональности
2) Вливание актульной ветви develop в текущую ветвь функциональности
3) Тестирование после слияния
4) публикование ветви функциональности в origin
5) запрос *Merge Request*, который должен быть готов к автоматическому слиянию.
```bash
# запускаем тесты
./run-tests
# перходим в ветвь develop
git checkout develop
git merge --no-ff myfeature
git branch -d myfeature
git push origin develop
# получаем крайние изменения
git pull
# переходим в функциональную ветвь
get checkout myfeature
# сливаем с ветвью develop
git merge develop
# устраняем конфликты и запускаем тесты
./run-tests
# заливаем функциональную ветвь в origin
git push origin myfeature
```
> Флаг --no-ff вынуждает Git всегда создавать новый объект коммита при слиянии, даже если слияние может быть осуществлено алгоритмом fast-forward. Это позволяет не терять информацию о том, что ветка существовала, и группирует вместе все внесённые изменения
![Ветвь функциональностей](img/feature_branches.png)
......@@ -66,7 +93,9 @@ git push origin develop
## Ветви релизов (release branches)
Порождаются от: develop
Вливаются в: develop и master
Соглашение о наименовании: release-*
Ветви релизов (release branches) используются для подготовки к выпуску новых версий продукта.
......@@ -80,9 +109,12 @@ git push origin develop
Ветвь релиза создаётся из ветви разработки (develop).
```bash
git checkout -b release-1.2 develop
git checkout develop
git pull
git checkout -b release-1.2
./bump-version.sh 1.2
git commit -a -m "Bumped version number to 1.2"
git push -u origin release-1.2
```
Эта новая ветвь может существовать ещё некоторое время, до тех пор, пока новый релиз окончательно не будет готов к выпуску. В течение этого времени к этой ветви (а не к develop) могут быть добавлены исправления найденных багов. Но добавление крупных новых изменений в эту ветвь строго запрещено. Они всегда должны вливаться в ветвь разработки (develop) и ждать следующего большого релиза.
......@@ -100,16 +132,25 @@ git commit -a -m "Bumped version number to 1.2"
```bash
git checkout master
git merge --no-ff release-1.2
git tag -a 1.2
git tag -a 1.2 -m "Version 1.2"
# --- если не в origin
# git push -u origin master
# git push origin 1.2
# ---
git checkout develop
git merge --no-ff release-1.2
git branch -d release-1.2
# --- если не в origin
# git push -u origin develop
# git push origin --delete release-1.0
```
## Ветви исправлений (hotfix branches)
Порождаются от: master
Вливаются в: develop и master
Соглашение о наименовании: hotfix-*
Ветви для исправлений (hotfix branches) используются для подготовки незапланированных выпусков продукта.
......@@ -130,6 +171,7 @@ git commit -m "Fixed severe production problem"
### Закрытие ветви исправлений
Когда баг исправлен, изменения надо влить обратно в главную ветвь (master), а также в ветвь разработки (develop), чтобы гарантировать, что это исправление окажется и в следующем релизе.
> У этого правила есть одно исключение: если в данный момент существует ветвь релиза (release branch), то ветвь исправления (hotfix branch) должна вливаться в неё, а не в ветвь разработки (develop)
```bash
......
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