# 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 [release|patch]-9.12.5.
  5. Push it git push origin [release|patch]-9.12.5.
  6. Create a MR: [release|path]-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 [relase|patch]-9.12.5.

# GIT recommendations

  • If you did some refactoring which is not related to your task, separate refactoring changes from actual changes required for your task. So it is better to create MR1 -> develop|master with actual changes and MR2 -> MR1 with refactoring.
  • 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. Write MR title in format TASK-ID title.
  2. Add yourself as Assignee.
  3. Add your team to Reviewers.
  4. Opt-in Delete source branch when merge request is accepted..
  5. Opt-in Squash commits when merge request is accepted.

# Merging checklist

  1. MR doesn't is not in Draft status.
  2. All discussions resolved.
  3. Checkboxes Remove source branch and Squash commits are checked.
  4. If project has approvement requirements, they are fulfilled.

# 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:

# Changelog Guidelines

  • Start every line with either New:, Bugfix:: or Removed:.
  • Be specific:
    • Bad: Bugfix: UI bug.
    • Good: Bugfix: Cloning from Favourite Streams doesn't work on new campaigns

# 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 local 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>