Branching Strategy

Main branches

• main → Main branch, represents the production state.
• stage → Staging branch, used for testing and integration before production.

General flow

• To deploy to staging, merge your branch into stage and deploy from there.
• When everything is validated, merge your branch into into main to release to production.
• Once a branch has been merged into main and everything is confirmed to be OK, delete it to keep the repository clean.

---

Naming convention

Each working branch follows this format:

<keyword>--<description>--<clickup-id>

Example:

feature--post-salesforce--86dxq5zn6

Keywords

Keyword	Recommended use
create	Add a new module or page
feature	Integrate a third-party service or add an endpoint
fix	Bug fixes
refactor	Code restructuring without changing functionality
design	Visual or design changes
test	Add or modify tests

Description

• Use kebab-case (lowercase with hyphens).
• Keep it short and descriptive.
• Avoid spaces, accents, or special characters.

ClickUp ID

• Add the ClickUp card ID at the end for task tracking.
• Example: --86dxq5zn6

---

Recommended workflow

1. Create a new branch from main:

   git checkout -b feature--post-salesforce--86dxq5zn6

2. Make the necessary changes and commits.
3. Open a pull request to stage.
4. Once reviewed and approved, merge into stage and deploy staging.
5. After successful validation, merge into main.
6. Delete the branch once merged into main and confirmed OK.

---

Example branch names

create--module-cta-aninmated--86dxq5zn6
feature--post-to-salesforce--86dxq5zn6
fix--error-slider--86dxq5zn6
refactor--php-8-compatible--86dxq5zn6
design--update-header-spacing--86dxq5zn6
test--animation--86dxq5zn6

---

Video

---

Reference

Inspired by:
GitHub branching name best practices – dev.to/jps27cse