Branching Guidelines and Conventions

There are many excellent naming conventions regarding git branches and commits. But what if you want something very lean and simple?

Branching Guidelines and Conventions

There are many excellent naming conventions regarding git branches and commits. But what if you want something very lean and simple?

Here is a proposition.

Categories of branches

Every code space should have a main and a development branch.
Apart from them, you can create any number of branches in your code base.

• main branch: Changes merged into the main branch will be reflected in a production environment.
• develop branch: Changes merged into the develop branch will be reflected in a test environment. All new feature branches of current sprint will be created from the develop branch. A git branch should start with a category. Pick one of these: feature, bugfix, hotfix, test, nojira.
• feature is for adding, refactoring, or removing a feature that is mentioned on any ticket or story created on Jira/ Youtrack. The feature branch should contain code related to only a single feature or ticket, which will be eventually merged into the develop branch. It should be created like feature/<ticket name>.
• bugfix is for fixing a bug mentioned on Jira/ Youtrack. These are the fixes to deploy on the test and stage environment. It should be created like bugfix/<ticket name>.
• hotfix is for changing code with a temporary solution and/or without following the usual process (usually because of an emergency). It is also used to deploy hotfix on production. It should be created like hotfix/<ticket name> or hotfix/<issue number>.
• test is for experimenting outside of an issue/ticket or having a spike ticket on Jira/ Youtrack. It should be created like test/<ticket name>.
• release is for the stage environment Changes merged into the release branch will be reflected in the stage environment. It should be created like release/<tag>
• Nojira is for the work that is not listed on Jira/Youtrack or work that has no reference ticket. It should be created like nojira/<short description of the work>

Git Process

During Sprint

1. Create a feature branch with ticket no. from the develop branch.
2. Work on that feature branch and at the end of the day, push your changes into that branch with the proper commit message below format: 
   feature/<ticket-no> | <user id / username> | proper commit description
   feature<XYZ-435> | SU-12 | Updated Error occurring in getting user API
3. Once your work is done, rebase your feature branch with the develop branch and create a Pull request against the develop branch, The PR title should be as below:
   feature/<ticket-no> | SU-12| <feature ticket title> 
   feature/<ticket-no> | SU-12| Generate random order number in admin
4. If the reviewer has posted improvements/fixes in PR, then push commits with the same message format with the proper description
5. Once PR is ready to merge the reviewer should squash and merge the branch into develop and delete the feature branch
6. If QA reports bugs in a test environment, create a new branch from the develop branch with format (bugfix/<ticket-no>) and generate PR against the develop branch. Reviewer should squash and merge the branch into develop and delete the fix branch

Code freeze (stage release/regression phase)

1. Create a new release branch from the main branch in this format (release_/<_tag> release/1.0.0, release/1.0.1) If all changes from the develop branch are required for the next release, rebase the develop branch on the newly created release branch by running the below command:
    Git checkout release/1.0.0
   Git rebase develop
   Git push origin release/1.0.0 (this will trigger stage deployment)
2. If only a few features(partial changes) are required for release, then cherry-pick commits from the develop branch into the release branch and push new commits.
3. Any changes pushed to the release branch will trigger stage deployment.
4. If any issues/bugs are found during code freeze, the fix needs to deploy on the stage environment first and then on a test environment.
5. For new bugs, create a new release branch from the last release branch, for example, release/1.0.1 from release/1.0.0, then create a new fix branch out of the new release branch with the below format: bugfix/<ticket-number>
6. Generate fix branch PR against new release branch(release/1.0.1). The reviewer should squash and merge the branch into the release branch and delete the fix branch
7. Once QA gives confirmation that the bug is fixed on the stage environment, the Developer should then rebase the release branch on the develop branch, so that the test environment will also have a new fix

Production release:

1. If all features/changes from the stage(release branch) environment are required to be released, then rebase the last release branch(e.g. release/1.0.6) on the main branch.
    Git checkout main
   Git rebase release/1.0.6
   Git push origin main
2. Once the changes are pushed, manually trigger production deployment from GitHub actions by selecting the main branch

Hotfix

1. Create a new release branch(release/1.2.0) from the master and create a hotfix branch out of the new release branch with the below format: hotfix/<ticket-no>
2. Work on hotfix and generate PR of hotfix branch against new release branch.
3. Reviewer should squash and merge the branch into the release branch and delete the hotfix branch
4. Once QA gives the confirmation of the hotfix on the stage environment, rebase the release branch on the main branch and trigger manual deployment from GitHub actions in order to deploy the hotfix on production.
5. Developer should then rebase the release branch on the develop branch so that the hotfix will be deployed on the test environment as well.

By Jatin Jain Saraf on August 24, 2023.