ACCID Branching Strategy

Recommended

ACCID Git treats branches as temporary coordination and commits as the durable record. The recommended model is trunk-based development with short-lived topic branches, protected main, automated quality gates, and release tags.

A disciplined main + dev or environment-promotion model can still be ACCID-compatible when dev is a protected staging/promotion boundary, not a second long-lived source of truth. The test is simple: work still integrates frequently, branches stay short-lived, and promotion from dev to main is routine, auditable, and automated where possible.

Why Trunk-Based Development

ACCID optimizes for small, reviewable, reversible changes. Trunk-based development supports that by keeping integration continuous: work branches live briefly, merge through checks, and disappear. The longer a branch lives, the more it becomes an alternate reality. Alternate realities are fun in cinema, less fun in Git history.

Decision Criteria

Trunk-based development is the ACCID default because it scores best against the values ACCID is built around: atomic work, durable history, fast review, continuous integration, and low operational drag. It is not declared “best” in the abstract; it is best-fit for the workflow ACCID is trying to make easy.

Criterion	Why it matters to ACCID	Trunk fit
Atomic changes	ACCID commits are meant to describe one coherent change with useful context.	Short-lived topic branches encourage small batches.
Continuous integration	History is only durable if it integrates cleanly and frequently.	`main` stays the shared integration point.
Review quality	Humans and AI reviewers both perform better on smaller diffs.	Small PRs keep review focused and fast.
Release readiness	ACCID favors a history where any point on `main` is understandable and recoverable.	Protected, green `main` can be tagged or deployed.
Agentic development	Multiple nanions can work concurrently only if branch ownership and integration stay clear.	One work item → one short-lived branch maps cleanly to agent sessions.

When Trunk Is Not the Best Fit

Trunk-based development is the default, not a mandate. Some teams have release constraints that deserve more structure.

Multiple supported product versions: use maintenance branches for active release lines.
App-store or hardware release windows: use temporary release branches when external approval gates control shipping.
Strict regulated environments: use environment or release branches if auditors require explicit promotion boundaries.
Immature test automation: do not pretend main is releasable until checks make that true.
Large migration waves: use expand-contract delivery and feature flags; reach for long-lived branches only when compatibility cannot be preserved.

In those cases, keep ACCID’s core discipline: branches may be longer-lived, but commits should remain atomic, conventional, consistent, immutable, and durable.

How This Recommendation Evolves

ACCID should keep improving as evidence changes. Revisit the branching recommendation when the project’s delivery model changes, when release governance changes, or when the tooling can enforce better safety than the process assumes today.

Measure: branch age, PR size, review latency, merge-conflict frequency, failed checks, rollback rate.
Review: revisit the strategy when metrics degrade or release constraints change.
Adapt: add release or maintenance branches only for concrete release needs, not habit.
Document: if a repo deviates from trunk, write down why and when the exception should be re-evaluated.

Branching Patterns in the Wild

Pattern	How it works	Strengths	Tradeoffs	ACCID stance
Trunk-based	Everyone integrates into protected `main` through short-lived branches.	Fast feedback, clean integration, fewer merge conflicts.	Requires discipline, tests, and feature flags for incomplete work.	Default recommendation.
GitHub Flow	Create a branch, open a PR, deploy from `main`.	Simple, popular, excellent for web apps and SaaS.	Can drift if branches stay open too long.	Compatible when branches stay short-lived.
GitLab Flow	Adds environment or release branches to GitHub Flow.	Good when deployments must flow through environments.	Environment branches can become hidden integration branches.	Acceptable when `dev` or environment branches are protected promotion boundaries, not alternate truth.
Git Flow	Long-lived `develop`, `release/`, and `hotfix/` branches.	Useful for packaged software with multiple release trains.	Heavy process, delayed integration, duplicate branch truth.	Avoid by default; reserve for multi-version maintenance.
Release branch train	Regular release branches are cut from main and stabilized.	Useful for scheduled releases and compliance-heavy environments.	Backports and cherry-picks add operational overhead.	Acceptable for external release constraints.

Recommended Branch Model

Branch	Purpose	Lifetime	Example
`main`	Protected integration and release branch.	Permanent	`main`
`feat/*`	New capability or product behavior.	Hours to a few days	`feat/SUR-123-accid-docs`
`fix/*`	Bug fix or corrective change.	Hours to a few days	`fix/SUR-456-session-race`
`chore/*`	Dependencies, tooling, maintenance, or cleanup.	Hours to a few days	`chore/SUR-789-upgrade-astro`
`release/*`	Temporary stabilization when releases require coordination.	Until release ships	`release/v1.4.0`
`hotfix/*`	Urgent production patch from the latest release baseline.	As short as possible	`hotfix/SUR-911-token-expiry`

Workflow Diagram

flowchart LR A[Work item ready] --> B[Create short-lived topic branch] B --> C[Make atomic ACCID commits] C --> D[Open PR] D --> E{Quality gates pass?} E -- No --> C E -- Yes --> F[Review approval] F --> G[Merge to protected main] G --> H[Tag release or deploy] H --> I[Delete topic branch]

Lifecycle Mapping

Branches should mirror work lifecycle. The work item owns intent; the branch is just the temporary execution surface.

stateDiagram-v2 [*] --> Todo Todo --> InProgress: create topic branch InProgress --> InReview: open PR InReview --> InProgress: changes requested InReview --> Main: approved + checks pass Main --> Released: deploy or tag Released --> Done: close work item InProgress --> Cancelled: abandon work Cancelled --> [*]: delete branch Done --> [*]

Protection Rules

Protect main. No direct pushes except emergency administrator actions with an audit trail.
Require pull requests. Every merge into main should pass review.
Require status checks. Build, test, lint, and security checks must pass before merge.
Require branch currency. Rebase or update the branch when stale if merge risk is non-trivial.
Require signed commits where appropriate. Use SSH/GPG signing for high-trust repositories.
Require linear history when practical. Prefer rebase or squash merge for short-lived branches; preserve meaningful ACCID commits when they carry useful history.
Require conversation resolution. All review threads must be resolved before merge.
Restrict force pushes on shared branches. Local cleanup is fine; rewriting shared review history should be intentional.

Release and Hotfix Handling

gitGraph commit id: "main green" branch feat/SUR-123 checkout feat/SUR-123 commit id: "ACCID commit" commit id: "tests" checkout main merge feat/SUR-123 id: "merge PR" commit id: "release prep" branch hotfix/SUR-911 checkout hotfix/SUR-911 commit id: "critical fix" checkout main merge hotfix/SUR-911 id: "hotfix merge" commit id: "tag v1.4.1"

Rules of Thumb

One branch should map to one work item or one coherent change.
If a branch cannot be reviewed comfortably, split the work.
If a branch lives longer than a few days, ask whether the scope is too large or hidden behind the wrong abstraction.
Use feature flags for incomplete product behavior; do not use long-lived branches as feature flags.
Use release tags for shipped versions; introduce maintenance branches only when supporting multiple live release lines.
Do not add develop unless it represents a real deployment or staging constraint, not nostalgia.
If you use main + dev, keep dev protected, green, frequently promoted, and free of abandoned work.