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

Корректировки с учетом использования Gitlab

parent e11d051d
# GitFlow
Модель ветвления в проекте
Модель ветвления в проекте при использовании Gitlab.
Версия 1.0
Версия 1.1
![Образец ветвления](img/title.png)
......@@ -19,6 +19,8 @@
Ветвь *develop* считается *основной ветвью разработки*. Хранящийся в ней код в любой момент времени должен содержать самые последние изданные изменения, необходимые для следующего релиза.
В gitlab эти ветви помечаются как *protected*. Недопускается коммитить в главные ветви, разрешено только вливать вспомогательные ветви.
## Вспомогательные ветви
Вспомогательные ветви используются для распараллеливания разработки между членами команды. В отличие от главных ветвей, эти ветви всегда имеют ограниченный срок жизни. Каждая из них в конечном итоге рано или поздно удаляется.
......@@ -43,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)
......@@ -84,10 +109,11 @@ 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"
# если не в origin
git push -u origin release-1.2
```
......
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