Here is an example of a workflow used on SFCC teams that consist of a few common types of branches, each with different roles:

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.

1. Checkout latest develop branch

2. Pull down the latest changes via git pull

3. Create a new branch with the structure fix/*, e.g. fix/123-broken-form

4. When you are ready to submit your code, submit a new Pull Request that merges your code into develop

5. 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.

1. Checkout latest develop branch

2. Pull down the latest changes via git pull

3. Create a new branch with the structure feature/*, e.g. feature/123-mobile-header

4. When you are ready to submit your code, submit a new Pull Request that merges your code into develop

5. 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.

1. Checkout latest develop branch

2. Pull down the latest changes via git pull

3. Create a new branch with the structure release/*, e.g. release/v1.2.3

4. When you are ready to submit your code, submit a new Pull Request that merges your code into main

5. 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.

1. Checkout latest main branch

2. Pull down the latest changes via git pull

3. Create a new branch with the structure hotfix/*, e.g. hotfix/mobile-menu

4. When you are ready to submit your code, submit a new Pull Request that merges your code into main

5. 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.

• [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