README.md 8.24 KB
Newer Older
1
2
3
4
# GitFlow

Модель ветвления в проекте

5
6
Версия 1.0

7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
![Образец ветвления](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/) [перевод первой статьи]