Workflow по работе с Git

При разработке есть три основных потребности:

1. Новые фичи
2. Хотфиксы
3. Рефакторинг

Разработка крупной фичи

Что такое крупная фича?

Крупная фича — это блок работы, который нужно катить в прод одновременно.
Крупная фича декомпозируется на более мелкие задачи, которые могут выполняться разными людьми.
Примеры крупных фич: новая страница, форма регистрации или ряд изменений на нескольких страницах, имеющих один продуктовый контекст.

Порядок работы над крупной фичей

• Создаётся ветка с говорящим названием, например, new-auth-page.
  С ней очень часто придётся работать, название должно быть запоминающимся.
  Не нужно использовать ветку develop, потому что одновременно можно разрабатывать несколько независимых фич.

• Крупная фича делится на более мелкие, которые оформляются как Pull Requests в фича-ветку. Основная часть работы — работа над такими небольшими тасками:

  1. Под каждый таск бранчимся от фича-ветки

     $ git checkout -b PN-1234
     

     Подсказка: Флаг -b (branch) означает, что нужно создать новую ветку и перейти в неё.

     Если вы используете систему тикетов, где у задач есть номера, название ветки должно совпадать с номером задачи. Это поможет найти ветку, если пришлось передать задачу от одного разработчика другому, поможет удалить старые ветки. Плюс, возможно, будут какие-то профиты от интеграции системы тикетов и репозитория. Если же у задач номеров нет, используйте говорящие названия. Неправильно: fix Правильно: fix-email-validation

  2. Пишем код;

  3. Коммитим согласно соглашению по именованию;

  4. Создаём Pull Request в фича-ветку;

  5. Если есть конфликты, нужно подмерджить фича-ветку и исправить их.

     $ git fetch
     $ git merge origin/feature-branch
     $ vim file.js # fix conflicts
     $ git commit
     

  6. Когда Pull Request смёрджен, ветка удаляется;

• Когда все мелкие фичи замерджены, крупная фича тестируется в своей ветке и отправляется в прод.

• Если всё ок, ветка мерджится в master.

Хотфиксы и небольшие фичи

Для хотфиксов и небольших фич заводится отдельная ветка от master, название ветки должно совпадать с номером задачи:

$ git checkout -b PN-1234

Подсказка: Флаг -b (branch) означает, что нужно создать новую ветку и перейти в неё.

После этого в ветке пишется и коммитится код, согласно соглашению по именованию:

$ git commit -m 'fix(scope): subject'

Ветка пушится и создаётся Pull Request в master:

$ git push -u origin PN-1234

Подсказка: Флаг -u или --set-upstream означает, что нужно связать локальную и remote ветку. Тогда в следующий раз не нужно будет писать remote и название ветки при git push и git pull.
Подсказка: Если вы хотите создавать Pull Requests из консоли, воспользуйтесь утилитой hub от GitHub и командой hub pull-request

Код отправляется в прод. Если на проде всё ок, ветка подмердживается в master.

Рефакторинг

Рефакторинг нужно делать от ветки master и как можно быстрее вливать в неё. Часто рефакторинг затрагивает много кода, если затянуть мердж в основную ветку, может быть много конфликтов. По этой же причине не нужно делать рефакторинг в фича-ветках. Если нужно что-то отрефакторить, чтобы написать новую функциональность, не ленитесь, создайте отдельную ветку под рефакторинг и сделайте Pull Request в master.

Релизы

Когда нужно подготовить релиз, от мастера заводится релиз-ветка. Название ветки должно совпадать с номером задачи или начинаться со слова release. Например, release-login-page, release-123 или release-15-12-2016. После этого в релиз-ветку подмердживаются нужные фичи/фиксы, составляющие релиз. Обязательно должна быть задача, отражающая состав релиза. После проводится тестирование и ветка отправляется в прод. Если на проде всё хорошо и решено оставить релиз в продакшене, ветка помердживается в master

Почему нужно сначала отправлять фичу в прод, а потом мерджить?

Почему не нужно использовать ветку develop