Branching Strategy - Naming, Lifecycle, Merge Strategies

Naming Conventions

Consistent prefixes make branches machine-parseable and instantly readable. Use lowercase, kebab-case only.

Branch naming prefixes, their purpose, and examples.
Prefix	Purpose	Example
`feature/`	New functionality	`feature/user-auth`
`fix/`	Bug fix	`fix/login-redirect`
`hotfix/`	Urgent production fix	`hotfix/payment-null`
`release/`	Release preparation	`release/2.1.0`
`chore/`	Maintenance, tooling	`chore/update-deps`
`docs/`	Documentation only	`docs/api-endpoints`
`test/`	Test additions	`test/auth-coverage`
`refactor/`	Code restructure, no logic change	`refactor/db-layer`

# Good
feature/user-authentication
fix/null-pointer-on-login
release/3.2.0

# Avoid
myBranch
JIRA-1234
wip

Branch Lifecycle

A defined lifecycle keeps branches short-lived and prevents drift from main.

SyncPull latest main before branching — never start from stale code.
CreateBranch with a prefixed, descriptive name. One purpose per branch.
DevelopCommit frequently with conventional messages. Stage intentional hunks, not whole files.
Push & ReviewPublish, open a PR with a clear description. Address feedback in focused follow-up commits.
Merge & DeleteMerge the approved PR. Delete the branch immediately — locally and remotely.

git done                          # 1. sync — fetch + rebase main
git cb feature/auth-refresh       # 2. create
git ap && git cm "feat(auth): add token refresh"  # 3. develop
git publish                       # 4. push + open PR
git co main && git pull           # 5a. after merge lands
git brd feature/auth-refresh      # 5b. delete local

Merge Strategies

How you merge shapes your history. Choose based on what you want preserved.

Comparison of squash merge, rebase merge, and merge commit strategies.
Strategy	Result	History	Use When
Squash Merge	One clean commit	Simple, linear	Small features, many WIP commits
Rebase Merge	Commits replayed on top	Linear, no merge commit	Personal branches, clean log preferred
Merge Commit	Merge commit + branch history	Complete, shows topology	Long-lived branches, preserve context

# squash WIP commits before merging
git squash                    # reset --soft HEAD~N then commit

# rebase branch onto latest main
git done                      # fetch + rebase origin/main

# preserve full branch history
git merge --no-ff feature/name

Short-Lived vs Long-Lived

Differences between short-lived and long-lived branches.
Criteria	Short-Lived	Long-Lived
Lifespan	Hours to a few days	Weeks to permanent
Conflict risk	Low — small diff	High — drifts from main
Examples	`feature/`, `fix/`, `chore/*`	`main`, `develop`, `release/*`
After merge	Delete immediately	Keep, protect
Merge strategy	Squash or rebase	Merge commit

Branch Protection

Enforce good habits at the repository level. Apply to main and develop in Gitflow.

No direct pushes to main — all changes via PR
Require at least 1 approving review before merge
Require all CI status checks to pass before merging
Dismiss stale approvals when new commits are pushed to the PR
Require the branch to be up-to-date with main before merging
Restrict who can force-push or delete the protected branch

Cleanup Commands

Stale branches add noise and slow down discovery. Run cleanup regularly.

git cleanup           # delete all locally merged branches
git gone              # find branches whose remote was deleted
git bra               # list all branches local + remote
git brd feature/name  # safe delete (fails if unmerged)
git brD feature/name  # force delete

Build Your Branch Discipline

Consistent naming and short-lived branches compound over time into a codebase that is easy to navigate, review, and debug. Start enforcing conventions today.

Choose a Workflow →Branch Aliases