README.md 9.39 KB
Newer Older
1
2
# GitFlow

3
Модель ветвления в проекте при использовании Gitlab.
4

5
Версия 1.1
6

7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
![Образец ветвления](img/title.png)


## Главные ветви

Репозиторий содержит две главные ветви, существующие всё время:

- master

- develop

В *master* исходный код находится в состоянии *production-ready* в любой произвольный момент времени.

Ветвь *develop* считается *основной ветвью разработки*. Хранящийся в ней код в любой момент времени должен содержать самые последние изданные изменения, необходимые для следующего релиза.

22
23
В gitlab эти ветви помечаются как *protected*. Недопускается коммитить в главные ветви, разрешено только вливать вспомогательные ветви.

24
25
26
27
28
29
30
31
32
33
34
35
36
## Вспомогательные ветви

Вспомогательные ветви используются для распараллеливания разработки между членами команды. В отличие от главных ветвей, эти ветви всегда имеют ограниченный срок жизни. Каждая из них в конечном итоге рано или поздно удаляется.

- Ветви функциональностей (Feature branches)

- Ветви релизов (Release branches)

- Ветви исправлений (Hotfix branches)

## Ветви функциональностей (feature branches)

Порождаются от: develop
37

38
Вливаются в: develop
39

40
41
42
43
44
45
46
47
Соглашение о наименовании: всё, за исключением master, develop, release-* или hotfix-*

При начале работы над новой функциональностью делается ответвление от ветви разработки (develop).

Когда работа в ветви завершена, последняя вливается обратно в главную ветвь разработки (что означает, что функциональность будет добавлена в грядущий релиз) или же удаляется (в случае неудачного эксперимента).

### Создание ветви функциональности (feature branch)

48
При начале работы над новой функциональностью на машине разработчика делается обновление ветки разработки (develop) и ответвление от нее.
49
50

```bash
51
52
53
git checkout develop
git pull
git checkout -b myfeature
54
55
56
57
58
59
```

### Добавление завершённой функциональности в develop

Завершённая функциональность (фича) вливается обратно в ветвь разработки (develop) и попадает в следующий релиз.

60
61
62
63
64
65
66
67
68
69
70
71
Общий порядок сливания ветви функциональности и основной ветви разработки:

1) Тестирование функциональности

2) Вливание актульной ветви develop в текущую ветвь функциональности

3) Тестирование после слияния

4) публикование ветви функциональности в origin

5) запрос *Merge Request*, который должен быть готов к автоматическому слиянию.

72
```bash
73
74
75
# запускаем тесты
./run-tests
# перходим в ветвь develop
76
git checkout develop
77
78
79
80
81
82
83
84
85
86
# получаем крайние изменения
git pull
# переходим в функциональную ветвь 
get checkout myfeature
# сливаем с ветвью develop
git merge develop
# устраняем конфликты и запускаем тесты
./run-tests
# заливаем функциональную ветвь в origin
git push origin myfeature
87
88
89
90
91
92
93
94
95
```


![Ветвь функциональностей](img/feature_branches.png)


## Ветви релизов (release branches)

Порождаются от: develop
96

97
Вливаются в: develop и master
98

99
100
101
102
103
104
105
106
107
108
109
110
111
Соглашение о наименовании: release-*

Ветви релизов (release branches) используются для подготовки к выпуску новых версий продукта.

Новую ветку релиза (release branch) надо порождать в тот момент, когда состояние ветви разработки полностью или почти полностью соответствует требованиям, соответствующим новому релизу.

Очередной релиз получает свой номер версии только в тот момент, когда для него создаётся новая ветвь, но ни в коем случае не раньше.

### Создание ветви релиза (release branch)

Ветвь релиза создаётся из ветви разработки (develop).

```bash
112
113
114
git checkout develop
git pull
git checkout -b release-1.2
115
116
./bump-version.sh 1.2
git commit -a -m "Bumped version number to 1.2"
117
git push -u origin release-1.2
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
```

Эта новая ветвь может существовать ещё некоторое время, до тех пор, пока новый релиз окончательно не будет готов к выпуску. В течение этого времени к этой ветви (а не к develop) могут быть добавлены исправления найденных багов. Но добавление крупных новых изменений в эту ветвь строго запрещено. Они всегда должны вливаться в ветвь разработки (develop) и ждать следующего большого релиза.

### Закрытие ветви релиза

Когда ветвь релиза (release branch) окончательно готова для выпуска, нужно выполнить следующее:

- ветвь релиза вливается в ветвь master

- коммит в master должен быть помечен тегом

- ветвь релиза вливается в ветвь develop

```bash
git checkout master
git merge --no-ff release-1.2
135
136
137
138
139
git tag -a 1.2 -m "Version 1.2"
# --- если не в origin
# git push -u origin master
# git push origin 1.2
# ---
140
141
142
git checkout develop
git merge --no-ff release-1.2
git branch -d release-1.2
143
144
145
# --- если не в origin 
# git push -u origin develop
# git push origin --delete release-1.0
146
147
148
149
150
```

## Ветви исправлений (hotfix branches)

Порождаются от: master
151

152
Вливаются в: develop и master
153

154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
Соглашение о наименовании: 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), чтобы гарантировать, что это исправление окажется и в следующем релизе.
174

175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
> У этого правила есть одно исключение: если в данный момент существует ветвь релиза (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/) [перевод первой статьи]