# GIT workflow
- Working on a story
- Workflow for patches
- GIT recommendations
- Release versioning
- Creating a merge request
- Embedding subprojects (git subtree)
- Changelog Guidelines
# Working on a story
# Prepare a branch
git checkout master(some projects can use
git pull origin master
git checkout -b PROJ-XXX
git push origin PROJ-XXX
- Create Merge Request of
PROJ-XXXto the parent branch (
hotfix-*) with prefix
# Finishing the story
Draft:prefix from the Merge Request name.
- Perform Code Review.
- 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:
- Checkout a current story branch
git checkout PROJ-XXX.
- Sync it
git pull origin PROJ-XXX.
- 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
- Pull all the tags
git pull --tags.
- Choose a version for the hotfix
git tag -l --sort=-v:refname.
- Checkout the latest patch
git checkout 9.12.4.
- Make a new branch with prefix "patch-"
git checkout -b [release|patch]-9.12.5.
- Push it
git push origin [release|patch]-9.12.5.
- Create a MR:
develop. That reminds you to merge patches to the upstream.
# Cherry picking bug-fixes from upstream
git cherry-pickin 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.
- 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|masterwith actual changes and
MR2 -> MR1with refactoring.
- Make and push commits regularly.
- Commits to an upstream must have Jira ID. E.g.,
PROJ-5222 your messageIf 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
- Write MR title in format
- Add yourself as
- Add your team to
Delete source branch when merge request is accepted..
Squash commits when merge request is accepted.
# Merging checklist
- MR doesn't is not in Draft status.
- All discussions resolved.
Remove source branchand
Squash commitsare checked.
- If project has approvement requirements, they are fulfilled.
- 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:
- https://www.atlassian.com/git/tutorials/git-subtree (opens new window)
- https://medium.com/@v/git-subtrees-a-tutorial-6ff568381844 (opens new window)
# Changelog Guidelines
- Start every line with either
- Be specific:
Bugfix: UI bug.
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:
If no then commit the changes.
Connect subtree to a folder:
git subtree add --prefix=<folder> <remote_namee> <git_branch>
master as a
# 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:
Upload commits from an external repository:
git subtree pull --squash --prefix=<folder> <remote_name> <git_branch>