Branching Strategy Overview

Main Branches

• master: The production branch. This is the branch that will be deployed to production.
• staging: The QA branch that mimics the production environment. This branch is used for testing before releasing to production.

Feature/Development Branches

• Developers create feature branches off the master branch for their work.
• Each feature branch should be named descriptively based on the feature or hotfix being developed (e.g., [ticket-id]-login-page). This can be copied from Linear.

Detailed Workflow

1. Creating Feature Branches

Developers branch off from the master branch to start new features or fixes:

git switch master
git pull origin master
git switch -c [ticket-id]-your-feature-branch

2. Development Process in Feature Branches

• Developers work in their feature branches and regularly push changes to the remote repository.
• Regular commits should be made, and interactive rebasing can be used to keep the commit history clean.

3. Deploying to Staging

Any feature or development branch can be deployed directly to the staging branch for QA testing:

git switch staging
git pull origin staging
git merge [ticket-id]-your-feature-branch
git push origin staging

4. Merging Feature Branches into Master

• When a feature is ready to be included in the production release:
• A pull request (PR) is created against the master branch.
• The PR should be reviewed and approved by at least one other developer.
• Once approved, the feature branch can be merged into master.

5. Syncing Staging with Master

Regularly synchronize staging with master to keep it up to date with the latest production code:

git switch staging
git pull origin staging
git merge master
git push origin staging

Alternatively, you can completely reset the staging branch to match master:

git switch staging
git reset --hard master
git push origin staging --force

6. Final Deployment to Production

• The master branch is deployed to the production environment.
• No direct commits are made to master; all changes come through approved pull requests.

Summary Diagram

master <--+--PR--- [ticket-id]/branch-1
           |
           +--PR-- [ticket-id]/branch-2
           |
           \--PR-- [ticket-id]/branch-n

staging <--+-- merge/rebase [ticket-id]/branch-1
             |
             +-- merge/rebase [ticket-id]/branch-2
             |
             \-- merge/rebase [ticket-id]/branch-n

(Regularly sync or reset from master to staging)