diff --git a/README.md b/README.md
index 94df83332966a637c1de015b65ee63e54d252c70..b04eb63d85563ffb112bdb4c781545c7f92eec42 100644
--- a/README.md
+++ b/README.md
@@ -1,8 +1,8 @@
 # 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