README.md in abak-flow-1.0.10 vs README.md in abak-flow-1.1.0

- old
+ new

@@ -1,90 +1,105 @@ Abak-flow ========= -Нет, это не новая идеология ведения проекта, это всего лишь набор утилит которые помогают связать использование [git-flow](https://github.com/nvie/gitflow) и [github flow](http://scottchacon.com/2011/08/31/github-flow.html) +[![Code Climate](https://codeclimate.com/github/Strech/abak-flow/badges/gpa.svg)](https://codeclimate.com/github/Strech/abak-flow) +[![Dependency Status](https://gemnasium.com/Strech/abak-flow.svg)](https://gemnasium.com/Strech/abak-flow) + +Нет, это не новая идеология ведения разработки в проекте, это всего лишь набор утилит которые помогают связать использование [git-flow](https://github.com/nvie/gitflow) и [github flow](http://scottchacon.com/2011/08/31/github-flow.html) + **Начиная с версии v0.2.1 используется авторизация OAuth2. [Как ей пользоваться?](https://github.com/Strech/abak-flow/wiki/How-start-work-with-new-abak-flow)** **Начиная с версии v1.0.0 используется новый формат конфигурации. [Как мигрировать старую?](https://github.com/Strech/abak-flow/wiki/How-start-work-with-abak-flow-v1.0.0)** -# Концепция -Идеология git-flow использует следующий набор веток: +**Начиная с версии v1.1.0 используется новый формат токена для Github API. [Как обновить?](https://github.com/Strech/abak-flow/wiki/How-start-work-with-abak-flow-v1.1.0)** -* *master* - всегда пригодна для развертывания -* *develop* - основная ветка разработки -* *hotfix* - ветка для изменений которые попадут на продакшен сервер -* *feature* - ветки для крупных задач - -Github-flow же наоборот ведет основную разработку в ветке master, но при этом master является пригодным для развертывания в любой момент. - -После долгих раздумий было принято применить следующий набор правил, для разработки на github: - -1. Вся разработка любой задачи и функционала ведется только в ветках **feature** -2. Разработаный функционал из ветки **feature** оформляется pull request только в ветку **develop** -3. Все исправления ошибок, которые должны попасть на продакшен сервер делаются только в ветках **hotfix** -4. Исправленные ошибки из ветки **hotfix** фофрмляются pull request только в ветку **master** -5. После получения исправлений на текущий момент в репозитории инициируется merge ветки **master** в **develop** - - # Установка - $ gem install abak-flow -v 1.0.0 + $ gem install abak-flow -v '>= 1.1.0' $ git config --global alias.request '!request' - $ git config --global abak-flow.oauth-user YOUR_GITHUB_MAIL@gmail.com - $ git config --global abak-flow.oauth-token 0123456789YOUR_GITHUB_API_TOKEN + $ git request configure $ git remote add upstream git://github.com/GITHUB_PROJECT_USER/GITHUB_PROJECT_NAME.git ### А если я использую прокси, как быть? - $ git config --global abak-flow.http-proxy http://my-proxy.com:3129 +При конфигурации вас спросят о прокси сервере. Если его нет, оставьте поле пустым + Далее по приоритету идут переменные окружения. Сначала **http_proxy**, затем **HTTP_PROXY** Т.е если вы используете переменные окружения, то просто не указывайте прокси в конфиге --- -**Заметьте:** В конфиге git, значением *abak.oauth-user* должен являться тот email адрес, под которым вы заходите на github +**Важно:** Пароль никогда и нигде не будет сохранен. Он [будет использован](https://developer.github.com/v3/#basic-authentication) для создания персонального токена -**Обратите внимание:** В данном контексте под **upstream** подразумевается адрес репозитория в который будут оформляться pull request. А репозиторием **origin** будет являться ваш форк +**Заметьте:** При конфигурации необходимо указать email адрес под которым вы заходите на github +**Обратите внимание:** В данном контексте под **upstream** подразумевается адрес репозитория в который будут оформляться пул реквесты. А репозиторием **origin** будет являться ваш форк + # С чего начать? $ git request checkup или $ git request help -**Примечание:** Вообще-то все комманды поддерживают опцию *--help*, но вот именно *git request --help* успевает перехватиться самим git и он конечно неодумевает как ему показать хэлп по внешней комманде +**Примечание:** Вообще-то все комманды поддерживают опцию `--help`, но вот именно `git request --help` успевает перехватиться самим git и он конечно неодумевает как ему показать хэлп по внешней комманде +# Список команд + + $ git request configure + $ git request checkup + $ git request compare [--base <имя ветки>] [--head <имя ветки>] + $ git request publish [--base <имя ветки>] [--head <имя ветки>] [--title <заголовок>] [--body <описание>] + $ git request done + +# Концепция +Идеология git-flow использует следующий набор веток: + +* *master* - всегда пригодна для развертывания +* *develop* - основная ветка разработки +* *hotfix* - ветка для изменений которые попадут на продакшен сервер +* *feature* - ветки для крупных задач + +Github-flow же наоборот ведет основную разработку в ветке master, но при этом master является пригодным для развертывания в любой момент. + +После долгих раздумий было принято применить следующий набор правил, для разработки на github: + +1. Вся разработка любой задачи и функционала ведется только в ветках **feature** +2. Разработаный функционал из ветки **feature** оформляется pull request только в ветку **develop** +3. Все исправления ошибок, которые должны попасть на продакшен сервер делаются только в ветках **hotfix** +4. Исправленные ошибки из ветки **hotfix** фофрмляются pull request только в ветку **master** +5. После получения исправлений на текущий момент в репозитории инициируется merge ветки **master** в **develop** + # Примеры использования ### Самый простой способ начать новую задачу: $ git checkout develop - $ git flow feature start 'TASK-001' + $ git checkout -b feature/TASK-001 $ touch 'hello.txt' && echo 'Hello world!' > hello.txt $ git commit -a -m 'Hello world commit' $ git request publish -**Внимание:** Не нужно называться ветку TASK. Используйте префикс задачь из jira +**Внимание:** Не нужно называться ветку TASK. Используйте префикс задач из jira Теперь то же самое, только словами: * Переключимся в ветку develop -* git-flow создаст ветку, пригодную для оформления pull request (правила именования и правила самого реквеста) +* Создадим ветку в которй будем выполнять задачу * Простое создание нового файла -* Git процедуры добавления своих изменений в репозиторий -* Затем публикация вашей ветки на вашем форке (если таковая уже есть, то просто обновление), затем оформление pull request из этой ветки в соответствующую правилам ветку на upstream (в данном случае это будет ветка develop) +* Git процедуры добавления своих изменений в индекс +* Затем публикация вашей ветки на вашем форке (если таковая уже есть, то просто обновление), затем оформление пул реквеста из этой ветки в соответствующую правилам ветку на upstream (в данном случае это будет ветка develop) Для задач, которые должны быть выполнены в виде hotfix принцип тот же: $ git checkout master - $ git flow hotfix start 'TASK-001' + $ git checkout -b hotfix/TASK-001 $ … $ git request publish -*На самом деле переключаться на master или develop в самом начале вовсе не обязательно, этот шаг был приведен для пущей ясности* +*На самом деле переключаться на master или develop в самом начале вовсе не обязательно, этот шаг был приведен для ясности* ## Маленькие хитрости Если сразу правильно именовать ветки, т.е ветку с задачей создавать с именем, такого формата TASK-001, то, в описание pull request автоматически вставится ссылка на задачу в jira, а в имя pull request сразу вставится название, состоящее из имени задачи, т.е TASK-001 Если делать реквест из ветки не соответствующей формату TASK-001, то в название подставится последний commit message. Если вы считаете, что нужно указать, что-то другое - всегда можно воспользоваться опцией `--title` @@ -97,6 +112,6 @@ # В заключении Данный репозиторий и изложенные в нем идеи ни в коем случае не претендуют на идеал и совершенство. Это всего лишь узко заточенная комбинация гемов ## Лицензия -Abak-flow выпускается под лицензией [MIT](http://www.opensource.org/licenses/MIT). \ No newline at end of file +Abak-flow выпускается под лицензией [MIT](http://www.opensource.org/licenses/MIT).