Master branch

• This is the main branch, whose code is deployed in the production environment and being used by the customer in live.
• No new branch can be created from master.
• No commits can be directly made in master branch.
• It should accept pull requests only from the staging branch and it should not accept pull requests from other branches including the develop branch.
• Should not have unreleased code [ every commit in master must have a stable release associated ]
• The pull request from the staging branch should be reviewed and approved by the client/stakeholder/productOwner.

Staging branch

• The code in this branch will be deployed in staging environment
• No direct commits are allowed.
• It should accept pull request only from the develop branch and it should not accept pull requests from other feature or bugfix branches.
• It can make a pull request only to the master branch.
• No new branch can be created from staging. In case of any issue is found while testing or deploying the code in staging branch, devfix/bugfix branch should be created only from the develop branch.
• Should not have unreleased code [ every commit in staging must have a beta release associated ]
• The pull request from the develop branch should be reviewed and approved by the tech lead/scrum master.

Develop branch

• The code in this branch will be deployed in development environment.
• No direct commits are allowed.
• It should accept pull requests only from the feature or bugfix branches and should not accept pull requests from user branches under any circumstance.
• It can make a pull request only to the staging branch.
• Should not have unreleased code [ every commit in develop must have an alpha release associated ]
• It is the base branch for feature or bugfix branches.

Feature branch

• Any new feature should have its own branch created from develop branch.
• The naming convention to follow for the feature branch is feature/$(x) where x denotes the name of the feature to be developed.
• Direct commits are allowed only when a single developer is working on the feature.
• In most of the projects, we will not have user branches. A feature will be owned by one developer.
• If multiple developers are working on the feature, pull requests need to be created from the user branches and merged.
• It can have unreleased code.

BugFix branch

• Any new bugfix should have its own branch created from develop branch.
• The naming convention to follow for the feature branch is bugfix/$(y) where y denotes the name of the bug to be fixed.
• Sometimes, when the bug is being fixed under multiple scenarios, we can use numbering or keyword denoting the scenarios to identify the bug. Hence the same bug can have multiple branches.
• Direct commits are allowed.
• It can have unreleased code.
• We can delete the branch after fixing the bug.