Every organisation using git version control needs a standard workflow to use the repo efficiently between teams as well as different environments.
Here I am explaining a beautiful workflow which you can try in your organisation.
We have 4 protected branches:
- main - This is the production branch which is used for production deployment
- release - The release branch contains production ready code.
Why this branch?
We have multiple developers working on different features. This branch is good to merge only the features needed to go to production. Before going to production we can test everything one again and make sure everything is okay to go to production. - uat - This branch is for user acceptance testing. This branch code will go to the UAT environment. This branch can be omitted from the workflow if you don't have a UAT environment.
- develop - This branch is for the development environment. Testers can test the features from this branch and assign back to developers for bug fixing.
Step to follow
- All feature, hotfix, fix branches should be created from the main branch.
- Once the feature is ready, the developers should create a merge request to develop branch.
- Testers can start testing. If any bug noted testers can assign the task back to developer.
- Developer can fix the issues and push back to develop branch using the same feature branch.
- If the test is okay, then developer can create a merge request against uat branch.
- If uat is okay, then developer can create a merge request against release branch.
- If release is okay to go production we can create MR to main branch.
- Create a tag with release notes on the main branch.
- Rebase release, uat and develop branch with main. So all are on the same head.
If two developers working on two features ie, ftr1 and ftr2 and ft1 requires ftr2 then ftr1 can merge ftr2. The same can be do with cherry-pick command. But extra commit will be added.
