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

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

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

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

# Когда делать merge

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

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

:::info Каждый MR - это чья-то уже законченная работа, поэтому уделяем ревью должное внимание. :::

  • Если вы числитесь в Assignees, от вас требуется реакция на MR:
    • Начинайте день с проверки текущих MergeRequest'ов. От вас требуется реакция в течение 48 часов. Если у вас нет вопросов, ставьте Approve.
    • Пишите все замечания сразу, чтобы создателю MR не приходилось постоянно переключаться между задачами.
    • Если наши опечатку, исправьте сами. В Gitlab есть возможность отредактировать файл прямо на странице MR. Этим вы сэкономите всем время.
    • Будьте максимально вежливы.
    • Старайтесь избегать прямых указаний, задавайте конкретные вопросы. Коллега может не иметь вашего бекграундра и может не понять пространственных наводящих вопросов.
    • Помните о синдроме красной ручки. Не будет лишним указать и на моменты, которые считаете получились удачно.
    • Разработка ведется итернативно, т.е. тратим минимум времени для достижения наилучшего результата. Если видите, что уже требуется масштабный рефакторинг, то заведите карточку в SOB - это полноценные истории, которым уделяем полноценное внимание.
    • Если заданный вами вопрос вопрос закрыт, нажмите Mark as Resolved. Иначе вы блокируете принятие MR.
  • Вы создатель MR:
    • Относитесь к ревью как к дополнительному обучению. Ваши коллеги помогут показать места для улучшения и ошибки. В целом качество кода будет повышаться.
    • Не ассоциируйте себя с кодом. Мы регулярно код переписываем, меняем архитектурно и даже удаляем.
  • Весь стиль кодирования должен проверяться автоматически через линтеры. На MR не должно тратититься время на исправление кавычек, пробелов и тд.

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

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

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

  • Рефакторинг - это полноценная История, следовательно на нее распространяются все рекомендации, что к Историям.
  • Убедитесь, что тесты покрывают логику, котору вы собираетесь рефакторить.
  • Придерживайтесь плана, в процессе легко увлечься.

# Встраивание подпроектов (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>

# FAQ

# Как почисить репозитори

git remote prune origin

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