Handbook

# Our git workflow

# Working on a Story

# Prepare the branch

  1. git checkout master (some projects can use develop for upstream).
  2. git pull origin master
  3. git checkout -b PROJ-XXX
  4. git push origin PROJ-XXX
  5. Create Merge Request of PROJ-XXX to the parent branch (master, develop or maybe hotfix-*) with prefix Draft:.

# Finishing the Story

  1. Remove Draft: prefix from the Merge Request.
  2. Perform Code Review
  3. Merge the MR. Some projects have a project leader who's resposible for approving MRs.

# How to working with a team on single Story

Story must be splitted to several sub-tasks. Every team member creates his own branch. The workflow is similiar as working on a Story:

  1. Checkout current Story branch git checkout PROJ-XXX
  2. Sync it git pull origin PROJ-XXX
  3. Create new branch for the subtask git checkout -b PROJ-YYYY

# Workflow for hotfixes

# Preparing the branch

  1. Pull all the tags git pull --tags
  2. Choose a version for the hotfix git tag -l --sort=-v:refname
  3. Checkout that version git checkout 9.12.4.2
  4. Make a new branch with prefix hotfix- git checkout -b hotfix-9.12.4.3
  5. Push it git push origin hotfix-9.12.4.3
  6. Create a MR with hotfix-9.12.4.3 as the source branch . That will help you to not forget to merge all the bug fixes to the upstream.

# Cherry picking fixes from upstream

  1. Use git cherry-pick in order to accumulate all the merged fixed from develop to the hotfix branch. Example: git cherry-pick ba47d721 -m 1
  2. Push the brahch git push origin hotfix-9.12.4.3

# Our git conventions

  • Make and push commits regularly.
  • Commits on upstream must have Jira's ID. Example, PROJ-5222 your message If you're working in branch and later intended to use squash commits, you can omit that.
  • Use Present Simple Tense for commit messages. Example, PROJ-5522 add README.md.

# Создание Merge-Request

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

  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

# Когда мержить

  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 →