Agile Git Workflow with Jira
This documentation will show the git standard workflow for medium sized to big tech companies.
When working with a system that would be use by thousands of users every second it would be best to separate the backend and frontend system.
For example:
PHP Laravel API - for the backend
React JS - for the front end
Step by step guide when creating new branch based on your task
After Cloning the specific repository, Branch out always to master/main branch
to avoid deprecated version.
Sample Git workflow:
Checkout master:
git checkout master
Make sure master is up to date:
git pull
Checkout feature branch:
git checkout feature/V1-1/create-user-roles
Branch name must based on the task you will develop, if itβs a Feature, Fix or Bug.
Also add to the Jira ticket number if available.
You can use slash for separator.
Example Branch name:
feature/V1-1/create-user-roles
Format:
[Feature, HotFix, Bug]/JIRA Ticket Number/task description
Git commit messages: Make useful and readable message when commit the branch.
And also add Jira ticket when making messages.
Format:
[Jira Ticket Number] [Feature, Bug, Fix] : commit messages
Example:
[V1-1] feature: adding user roles migratons
This is a very useful convention when integrating with Jira and Github.
Push the new branch
git push --set-upstream origin develop feature/V1-1/create-user-roles
Merge/Pull request: Always request to the develop branch only, to avoid issues on the master/develop
Branch
The tech lead or tech manager will be the one to merge and combine the pull requests.
Always check carefully your Jira ticket number when creating and commit branch.
This will help the team to add changelog to Jira task from Github commit.
When you are currently working on a task and need to update the master
branch without deleting your progress or messing up the codes you can do a git stash
.
git stash
Update the master/main branch
git pull origin master
Bring your changes back
git stash pop
Branch Tagging/Versioning
All task from the Sprint will be merged to the develop
branch once itβs already done from code review/checking
Develop Branch must be compared to the main/master
Branch if thereβs any conflicts and Behind/Ahead commits.
Merge Develop branch to master branch once it already clean from any conflicts.
Make semantic number from the master branch to create a release/tags
versioning
Sample Tags Versioning
userapi - V1
userchatapi - V2
Instructions
Format:
MAJOR.MINOR.PATCH
- 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.
Example:
v1.0.0
Semantic versioning is very useful for the deployment process when it comes to Production servers, You can easily rollback
specific version from the clean version when the installed version is buggy.
Top comments (0)