# Git Branch Workflows

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:

![Gitflow Workflow](https://findbycolor-github.s3.amazonaws.com/dev-workflow.png align="left")

# 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](https://semver.org/), 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.

| 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