Common Branching Strategy

The branching strategy may be different for each project. However, we can follow a standard way when we have a new project. Mainly, we are following the Scaled TBD(Trunk-Based Development).

Common Branch Summary

Branch	Live	Description
main	long	ready to publish (for UAT and Production) - After merged from a feature, it will deploy to UAT environment - Tester will test it in the UAT environment - After finish the UAT, it will deploy to Production
feature/{ticketID-short-feature-name}	short	feature work has a own branch (Eg. 1234-add-my-feature) - After opening PR, it will be deployed to DEV environment - After approved by QA, it will be merged into the main branch - In the main, it will deploy the UAT and PROD - After merged into the main, it should be deleted
bugfix/{ticketID-short-bugfix-name}	short	to fix a bug same as above the process of the deployment
research/{ticketID-short-name}	short	a research, experiment or investigation and will NOT merge to main (optional)

• Short-lived branches should be removed after merging into the main branch. (at the end of the sprint)

Basic Rule

Developers need to learn how to work in small batches, implement synchronized reviews and automated unit testing. Part of the definition of done is to deliver the feature to the main branch.

Develop Features

• Create a feature branch from the main branch.

• If someone merged his PR into the main, you should update your feature branch or PR by merge back.

• To merge the conflicts below, you need to resolve all the conflicts before proceeding to the next step.

  • squash and merge
  • rebase and merge
  • cherry-pick
  • git stash pop

Automation

• Github or Azure DevOps pipeline scripts will trigger in the middle of pull-request in both features and release branches (Git tag automation, test, build, and deploy for each environment)
• You can see artifacts after finish the build and pipeline process. However, Because it depends on a project, please check more detail per project.

Feature branches

In the case of feature branches, app developers have to check whether they are short-lived and practice daily merges into the code trunk. It’s better for the development team to run regular tests and reviews. Project ID is optional.

• Branch naming: feature/[ProjectID]-{ticket number}-short-name
  • Normal: feature/1234-remove-the-logo (recommended)
  • Github Project with Jira ID: feature/SML-1234-remove-the-logo
  • Choosi Project: feature/choosi-1234-remove-the-logo
  • Azure DevOps Project: feature/ADO-1234-remove-the-logo

Bugfix branches

After taking care of feature branches, we can choose one of bug tickets and fix it based on priorities.

• Branch naming: bugfix/{ticket number}-short-name
  • bugfix/1234-fix-padding-problem
  • Same as above

Work Items

For chores, refactoring, and repeat works, mostly, we use feature but, the name can be work.

• Branch naming: work/{ticket number}-short-name

Research (Optional)

Anything need to investigate, this is usually NOT merge into the main branch.

• Branch naming: research/{ticket number}-short-name