Skip to content

HTTPS clone URL

Subversion checkout URL

You can clone with HTTPS or Subversion.

Download ZIP
Abak press github + gitflow flow

Fetching latest commit…

Cannot retrieve the latest commit at this time

Failed to load latest commit information.
bin
lib
spec
.gitignore feature(all) total refactoring
.travis.yml
Gemfile
README.md
Rakefile
abak-flow.gemspec

README.md

Abak-flow

Code Climate Dependency Status Gem Version

Нет, это не новая идеология ведения разработки в проекте, это всего лишь набор утилит которые помогают связать использование 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.

Something went wrong with that request. Please try again.