Git Workflow with Agile Jira for Beginners

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 its 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 its already done from code review/checking

Develop Branch must be compared to the main/master Branch if theres 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.