Handbook

# GIT workflow

# Working on a story

# Prepare a 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 name.
  2. Perform Code Review.
  3. Merge the MR. Some projects have a project leader who's resposible for approving MRs.

# How to work with a team on a single story

A story must be split into several sub-tasks. Every team member creates their own branch. The workflow is similar to working on a story:

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

# Workflow for patches

We use a slightly different workflow for patches.

# 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 the latest patch git checkout 9.12.4.
  4. Make a new branch with prefix "patch-" git checkout -b patch-9.12.5.
  5. Push it git push origin patch-9.12.5.
  6. Create a MR: patch-9.12.5 to develop. That reminds you to merge patches to the upstream.

# Cherry picking bug-fixes from upstream

  1. Use git cherry-pick in order to collect all required bugs fixed from an upstream. E.g.: git cherry-pick ba47d721 -m 1. Also, you can use Gitlab UI to make a cherry-pick. Open merged MR and click a cherry-pick button.
  2. Push the brahch git push origin patch-9.12.5.

# GIT recommendations

  • Make and push commits regularly.
  • Commits to an upstream must have Jira ID. E.g., PROJ-5222 your message If you're working in a branch and later intends to use squash commits, you can omit to add Jira ID.
  • Use Present Simple tense for commit messages. E.g., PROJ-5522 add README.md.

# Release versioning

We follow SemVer 2.0 (opens new window) conventions.

+------- MAJOR version when you make incompatible API changes,
| +----- MINOR version when you add functionality in a backwards compatible manner, and
| | +--- PATCH version when you make backwards compatible bug fixes.
| | |
x.x.x

# Creating a merge request

# Guidelines

  1. Put "TASK-ID title" to the MR name. E.g., "GDBC-2244 adding Autocert server".
  2. Assign the MR to everyone you need feedback from.
  3. Check Delete source branch when merge request is accepted..
  4. Check Squash commits when merge request is accepted.

# When to merge

  1. Make sure the project does not have DRAFT: or WIP: prefix in the title.
  2. Pay attention to X/Y discussions resolved filed. It shows the number of comments and how many of them were checked ✓. All dialogues should be resolved.
  3. Check Remove source branch before merging. If this is your branch check Squash commits.

# Refactoring

  • Plan refactoring in Avion.
  • Make sure tests cover the code you are going to change.
  • Make the plan of what you are going to change and keep to it.

# Embedding subprojects (git subtree)

Using Git Subtree is more preferable to using Git Submodules as it gives more control on embedding projects and their updates. The manual is based on the articles:

# Adding the second repository as a subtree

Add a new repository as a remote upstream:

git remote add <remote_name> <git_url>

Make sure you commit all changes:

git status

If no then commit the changes.

Connect subtree to a folder:

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

Use master as a git_branch.

# Push changes to subtree

Perform an ordinary commit:

git commit -a

Push substree changes to the source repository:

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

# Pull of subtree changes

Make sure you commit all changes:

git status

Upload commits from an external repository:

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

← Code Review →