Нет, это не новая идеология ведения разработки в проекте, это всего лишь набор утилит которые помогают связать использование git-flow и github flow

Начиная с версии v0.2.1 используется авторизация OAuth2. Как ей пользоваться?

Начиная с версии v1.0.0 используется новый формат конфигурации. Как мигрировать старую?

Начиная с версии v1.1.0 используется новый формат токена для Github API. Как обновить?

$ gem install abak-flow -v '>= 1.1.0'
$ git config --global alias.request '!request'
$ git request configure
$ git remote add upstream git://github.com/GITHUB_PROJECT_USER/GITHUB_PROJECT_NAME.git

При конфигурации вас спросят о прокси сервере. Если его нет, оставьте поле пустым

Далее по приоритету идут переменные окружения. Сначала http_proxy, затем HTTP_PROXY

Т.е если вы используете переменные окружения, то просто не указывайте прокси в конфиге

Важно: Пароль никогда и нигде не будет сохранен. Он будет использован для создания персонального токена

Заметьте: При конфигурации необходимо указать email адрес под которым вы заходите на github

Обратите внимание: В данном контексте под upstream подразумевается адрес репозитория в который будут оформляться пул реквесты. А репозиторием origin будет являться ваш форк

$ git request checkup

или

$ git request help

Примечание: Вообще-то все комманды поддерживают опцию --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 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

Теперь то же самое, только словами:

• Переключимся в ветку develop
• Создадим ветку в которй будем выполнять задачу
• Простое создание нового файла
• Git процедуры добавления своих изменений в индекс
• Затем публикация вашей ветки на вашем форке (если таковая уже есть, то просто обновление), затем оформление пул реквеста из этой ветки в соответствующую правилам ветку на upstream (в данном случае это будет ветка develop)

Для задач, которые должны быть выполнены в виде hotfix принцип тот же:

$ git checkout master
$ git checkout -b hotfix/TASK-001
$ …
$ git request publish

На самом деле переключаться на master или develop в самом начале вовсе не обязательно, этот шаг был приведен для ясности

Если сразу правильно именовать ветки, т.е ветку с задачей создавать с именем, такого формата TASK-001, то, в описание pull request автоматически вставится ссылка на задачу в jira, а в имя pull request сразу вставится название, состоящее из имени задачи, т.е TASK-001

Если делать реквест из ветки не соответствующей формату TASK-001, то в название подставится последний commit message. Если вы считаете, что нужно указать, что-то другое - всегда можно воспользоваться опцией --title

Многие команды имеют какие-то дополнительные опции. Но они нужны только в экзотических случаях. Но при любом раскладе подсказку и тонкий намек всегда можно получить воспользовавших такой командой:

$ git request publish --help

Данный репозиторий и изложенные в нем идеи ни в коем случае не претендуют на идеал и совершенство. Это всего лишь узко заточенная комбинация гемов

Abak-flow выпускается под лицензией MIT.