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 (отсюда)

# Gitflow для проектов с поддержкой нескольких версий

# Инициализация репозитория

  1. git pull
  2. git flow init. На все вопросы оставляем значения по умолчанию.

# Разработка

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

  1. git checkout develop
  2. git pull origin develop
  3. Создаем фичу по имени истории git flow feature start story_feature_name
  4. Если над Историей работает неколько человек - git flow feature publish story_feature_name
  5. Создаем MR вашей фичи в develop. Если разработка еще не завершена, ставим метку WIP.

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

WARNING

Если над Историей работаете только вы, пропустите этот раздел. Работайте в ветке истории.

  1. git checkout story_feature_name
  2. git pull origin story_feature_name
  3. Заведите фичу подзадачи от фичи Истории git flow feature start subtask_feature_name story_feature_name
  4. По готовности git flow feature publish subtask_feature_name и создаем MR вашей фичи в ветку Истории

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

# Подготовка

  1. git flow hotfix start hf-<номер версии>
  2. git flow hotfix publish hf-<номер версии>

# Разработка

  1. git flow feature start PROJ-123 hotfix/hf-<номер версии>
  2. git flow feature publish PROJ-123
  3. Создаем MR из feature/PROJ-123 в hotfix/hf-<номер версии>

# Упрощенный Gitflow для простых проектов

  1. Создаем пустую ветку git checkout -b dummy
  2. git flow init:
    1. Для Branch name for production releases: пишем dummy
    2. Для Branch name for "next release" development: пишем master
    3. На остальные вопросы оставляем дефолтные значения

# Разработка

  1. git checkout master
  2. git pull origin master
  3. git flow feature start story_feature_name
  4. git flow feature publish story_feature_name

# Деплой

Каждый проект должен деплоить себя сам. Для этого настраиваем автодеплой в Gitlab CI/CD у ветки master.

# 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 - это сколько было замечаний и сколько из них отмечены галочкой ✓. Крайте важно, чтоб были отмечены все.
  3. Перед сливанием ставьте галочку "Remove source branch".

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

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

  • Начинайте день с проверки текущих MergeRequest'ов, где вы отмечены как Assignee. Если все ок, ставьте Approve. Список MR можно найти на странице To-Do List
  • При появлении уведомлений о новом MR, старайтесь при первой же возможности посмотреть его.
  • Задавайте вопросы. Например, вместо "Здесь используй библиотеку iconv", пишите "Почему бы не использовать библиотеку iconv?"
  • Ваш опыт отличается от остальных. Если вам что-то кажется очевидным, не полагайте, что и другому тоже.
  • Будьте вежливы. Если код не достигает нужного уровня качества, вежливо предлагайте улучшения и не забывайте заворачивать в форму вопроса.
  • Если вашу просьбу выполнили, ставьте маркировку Mark as Resolved на сообщении и всех ответах.
  • Если у вас нет вопросов, ставьте Approve или какой-нибудь emoji. Например, 👀.

WARNING

Если вас отметили как один из Assignee, постарайтесь заглянуть на него в течение 48 часов. Хотя бы поставьте эмоджи 👀.

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

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

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

  1. Составьте план и заведите историю.
  2. Убедитесь, что тесты покрывает участок, который вы собираетесь рефакторить. Если их мало, нужно сначала дописать.
  3. Следуйте плану и стремитесь держать тесты после каждого этапа зелеными. В процессе легко увлечься.

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