Handbook

# Apliteni git-flow

# Установка плагина git-flow-avh

  1. Установка описана здесь
  2. Для Windows плагин включен в Git for Windows (отсюда)
  3. Для Mac OS brew install git-flow-avh (отсюда)
  4. Для Ubuntu sudo apt-get install git-flow (отсюда)

# Деплой

Каждый проект должен деплоить себя сам.

# Упрощенный GIT Flow

# Разработка Истории

  1. git checkout master
  2. git pull origin master
  3. git checkout -b STORY-ID
  4. git push origin STORY-ID
  5. Оформляем MR ветки STORY-ID в master.

# GIT Flow для продуктовой разработки

# Разразработка Истории

  1. git checkout develop
  2. git pull origin develop
  3. Создаем ветку по имени истории git checkout -b STORY-ID
  4. git push origin STORY-ID
  5. Создаем MR в develop. Если разработка еще не завершена, ставим метку WIP.

# Разработка подзадач

WARNING

Если над Историей работаете только вы, нет необходимости создавать ветки на подзадачи.

  1. git checkout STORY-ID
  2. git pull origin STORY-ID
  3. Заведите фичу подзадачи от фичи Истории git checkout -b SUBTASK-ID
  4. По готовности git push origin SUBTASK-ID и создаем MR вашей фичи в ветку Истории

# Хотфикс старой версии продукта

# Подготовка

  1. Делаем чекаут из тега git checkout vX.X.X (X.X.X - это номер версии, для который делается патч)
  2. Заводим ветку git checkout -b hotfix-X.X.X

# Разработка

  1. git checkout -b BUG-ID
  2. git push origin BUG-ID
  3. Создаем MR ветки BUG-ID в hotfix-X.X.X

# Рекомендации к коммитам

  • Делайте коммиты чаще. Если комментарий содержит запятые или точки, то это признак того, что коммит у вас слишком большой. При сливании, мы включаем Squash commits, чтобы все коммиты ветки стали одним в после сливания.
  • Комментарий коммита начинается с номера задачи (Например, "GDBC-1233 add configuration file for postgres").
  • Комментарий пишется на английском. На грамматику не обращаем внимания, но всё-же стараемся писать аккуратно. Для простоты используйте Present Tense.

# Code-Review и работа с Merge-Request'ами (MR)

# Рекомендации к созданию MR

  1. В Title пишем "TASK-ID Заголовок". Пример "GDBC-2244 подключение сервера Autocert".
  2. В Assignees указываем всех, от кого нужен финдбек.
  3. Ставьте галочку Delete source branch when merge request is accepted..
  4. Ставьте галочку Squash commits when merge request is accepted

# Рекомендации по Code Review

Для тех, кто проверяет:

  • Начинайте день с проверки текущих MergeRequest'ов. Если у вас нет вопросов, ставьте Approve.
  • Оставьте все комментарии в рамках одной Code Review сессии. Не забудьте нажать на "Finish Code Review".
  • Если нашли маленьку опечатку, исправьте ее. Нажмите на иконку карандраша и внесите изменения. Этим вы сбережете всем время.
  • Старайтесь избегать прямых указаний, задавайте конкретные вопросы. Коллега может не иметь вашего опыта и может не понять пространственных вопросов.
  • Помните об интеративности разработки. Код не должен быть идеальным, но не откладывайте на долго рефакторинг, если накопился технических долг.
  • Если заданный вами вопрос решен, нажмите Mark as Resolved. Тот кто оставил комментарий должен следить за его завершением.
  • Весь стиль кодирования должен проверяться автоматически через линтеры. Если видите, что нарушен стиль, доработайте правила линтера.

Для тех, кто создал MR:

  • Code Review может занимать до 2х суток. Если на вторые сутки вы не получили реакции, зовите нужных людей в рамка утреннего "MR Digest".
  • Относитесь к ревью как к дополнительному обучению. Ваши коллеги помогут показать места для улучшения и ошибки. В целом качество кода будет повышаться.
  • Не ассоциируйте себя с кодом. Комментарии коллег относятся к коду, не нужно воспринимать это как личную критику.

# Когда сливать

  1. Проверьте, что у проекта нет метки DRAFT: или WIP: в Title.
  2. Обратите внимание на блок X/Y discussions resolved - это сколько было замечаний и сколько из них отмечены галочкой ✓. Все диалоги должны быть разрешены (Resolved).
  3. Перед сливанием ставьте галочку "Remove source branch". Если это ваша ветка, ставим Squash commits.

# Рефакторинг

  • Планируйте рефакторинг через SOB.
  • Убедитесь, что тесты покрывают код, который вы собираетесь менять.
  • Не увлекайтесь. Сделайте план того, что будете менять и придерживайтесь его.

# Встраивание подпроектов (git subtree)

Использование Git Subtree предпочтительнее, чем Git Submodules, т.к. дает больше контроля за встроенными проектами и их обновлением. Инструкция основана на статьях:

# Добавление второго репозитория как substree

Добавляем новый репозиторий как remote upstream:

git remote add <remote_name> <git_url>

Убедитесь, что у вас все изменения закоммичены:

git status

Если нет, нужно закоммитить.

Подключаем subtree к папке:

git subtree add --prefix=<folder> <remote_namee> <git_branch>

Ветку git_branch желательно всегда использовать master.

# Push изменений у subtree

Делаем обычный commit:

git commit -a

Пушим изменения substree в исходный репозиторий:

git subtree push --prefix=<folder> <remote_name> <git_branch>

# Pull изменений subtree

Убедитесь, что все изменения закоммичены

git status

Подгржаем коммиты с внешнего репозитория:

git subtree pull --squash --prefix=<folder> <remote_name> <git_branch>

← Соглашения и code style →