README.md in abak-flow-0.1.1 vs README.md in abak-flow-0.1.2

@@ -1,16 +1,16 @@
 Abak-flow
 =========
 Нет, это не новая идеология ведения проекта, это всего лишь набор утилит которые помогают связать использование git-flow и github
 
 # Концепция
-Идеология git-flow использует слудующий набор веток:
+Идеология git-flow использует следующий набор веток:
 
 * *master* - всегда пригодна для развертывания
 * *develop* - основная ветка разработки
 * *hotfix* - ветка для изменений которые попадут на продакшен сервер
-* *feature* - ветки для крупных задачь
+* *feature* - ветки для крупных задач
 
 Github-flow же наоборот ведет основную разработку в ветке master, но при этом master является пригодным для развертывания в любой момент.
 
 После долгих раздумий было принято применить следующий набор правил, для разработки на github:
 
@@ -20,15 +20,73 @@
 4. Исправленные ошибки из ветки **hotfix** фофрмляются pull request только в ветку **master**
 5. После получения исправлений на текущий момент в репозитории инициируется merge ветки **master** в **develop**
 
 
 # Установка
-*в процессе*
 
+    $ gem install abak-flow
+    $ git config --global alias.request '!request'
+    $ git config --global github.user AwesomeCoder
+    $ git config --global github.token 0123456789yourf0123456789token
+    $ git remote add upstream git://github.com/anonimus/example.git
+
 # С чего начать?
-    $ git request help
 
+    $ git request --help
+
 # Примеры использования
-*в процессе*
+### Самый простой способ начать новую задачу:
+
+    $ git checkout develop
+    $ git request feature
+    $ touch 'hello.txt' && echo 'Hello world!' > hello.txt
+    $ git commit -a -m 'Hello world commit'
+    $ git request publish
+
+Теперь то же самое, только словами:
+
+* Переключимся в ветку develop
+* Abak-flow создаст ветку, пригодную для оформления pull request (правила именования и правила самого реквеста)
+* Простое создание нового файла
+* Git процедуры добавления своих изменений в репозиторий
+* Затем публикация вашей ветки на вашем форке (если таковая уже есть, то просто обновление), затем оформление pull request из этой ветки в соответствующую правилам ветку на upstream (в данном случае это будет ветка develop)
+
+Для задач, которые должны быть выполнены в виде hotfix принцип тот же:
+
+    $ git checkout master
+    $ git request hotfix
+    $ …
+    $ git request publish
+
+*На самом деле переключаться на master или develop в самом начале вовсе не обязательно, этот шаг был приведен для пущей ясности*
+
+### Обновление ветки на удаленном репозитории:
+
+    $ git checkout feature/TASK-001
+    $ git request update
+
+### Завершение текущей задачи:
+Вообще, завершать задачу лучше только после того, как ваш pull request был принят. Почему? На самом деле по ряду причин. По умолчанию эта команда удаляет как вашу текущую ветку с задачей в локальном репозитории и в добавок ко всему - на вашем удаленном репозитории (форке)
+
+    $ git co feature/TASK-001
+    $ git request done 
+
+Чтобы оставить какую либо ветку в живых возможно напрямую указать, какую копию ветки **удалить**, локальную или же удаленную (на origin)
+
+    $ git co feature/TASK-001
+    $ git request done --origin
+
+Или же так
+
+    $ git co feature/TASK-001
+    $ git request done --local
+
+### Маленькие хитрости
+Если сразу правильно именовать ветки, т.е ветку с задачей создавать с именем, такого формата TASK-001, то, в описание pull request автоматически вставится ссылка на задачу в jira
+
+### А помощь?
+Многие команды имеют какие-то дополнительные опции. Но они нужны только в экзотических случаях. Но при любом раскладе подсказку и тонкий намек всегда можно получить воспользовавших такой командой:
+
+    $ git request done --help
 
 # В заключении
 Данный репозиторий и изложенные в нем идеи ни в коем случае не претендуют на идеал и совершенство. Это всего лишь узко заточенная комбинация гемов
\ No newline at end of file