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

README.md

+# 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/) [перевод первой статьи]
+