Here is an example of a workflow used on SFCC teams that consist of a few common types of branches, each with different roles:
| BRANCH | EXAMPLE | ROLE |
develop | - | Integration Branch before Merging into main |
main | - | Production Ready Code |
fix/* | fix/123-broken-form | Based on latest develop and Issue Specific |
feature/* | feature/123-mobile-header | Based on latest develop and Feature Specific |
release/* | release/v1.2.3 | Based on latest develop and Release Specific |
hotfix/* | hotfix/mobile-menu | Based on latest main and Hotfix Specific |
Here is an example of how code flows through this repository:
Creating New Branches
We suggest using naming conventions for creating and managing branches.
Fix
Each Bug Fix reported should have its own fix/* branch. The branch name should be formatted fix/###-issue-name where ### is the Issue Number, and issue-name is a 1-3 word summary of the issue.
Checkout latest develop branch
Pull down the latest changes via git pull
Create a new branch with the structure fix/*, e.g. fix/123-broken-form
When you are ready to submit your code, submit a new Pull Request that merges your code into develop
Tag your new Pull Request with Ready for Code Review
Feature
Each New Feature should reside in its own feature/ branch. The branch name should be formatted feature/###-feature-name where ### is the Issue Number, and feature-name is a 1-3 word summary of the feature.
Checkout latest develop branch
Pull down the latest changes via git pull
Create a new branch with the structure feature/*, e.g. feature/123-mobile-header
When you are ready to submit your code, submit a new Pull Request that merges your code into develop
Tag your new Pull Request with Ready for Code Review
Release
Each New Release should reside in its own release/ branch. The branch name should be formatted release/v#.#.# where v#.#.# is the next version number to be deployed. Our version numbers use Semantic Versioning, e.g. MAJOR.MINOR.PATCH.
NOTE: New Release Branches should only be created by the Release Manager.
Checkout latest develop branch
Pull down the latest changes via git pull
Create a new branch with the structure release/*, e.g. release/v1.2.3
When you are ready to submit your code, submit a new Pull Request that merges your code into main
Tag your new Pull Request with Ready for Code Review
Hotfix
Emergency Hotfixes should reside in their own hotfix/ branch. The branch name should be formatted hotfix/hotfix-name where hotfix-name is a 1-3 word summary of the new hotfix.
NOTE: New Hotfix Branches should only be created by the Release Manager.
Checkout latest main branch
Pull down the latest changes via git pull
Create a new branch with the structure hotfix/*, e.g. hotfix/mobile-menu
When you are ready to submit your code, submit a new Pull Request that merges your code into main
Tag your new Pull Request with Ready for Code Review
Continuous Integration
We have three Environments set up for every project, each set up with Continuous Integration and independent URLs for testing.
| ENVIRONMENT | TAG | BRANCH | SOURCE BRANCH |
| vx.x.x | - | main |
| staging-* | - | release/* or hotfix/* |
| - | develop | develop |
[X] Production is deployed when a Tagged Branch matching vx.x.x is created from main
[X] Staging is deployed when a Tagged Branch matching staging-* is created from a release/* or hotfix/* branch
[X] Development is deployed with any Pull Request that is merged into the develop branch
