ACCID Git

Stable

ACCID Git (Atomic Conventional Consistent Immutable Durable) is a comprehensive Git workflow standard that elevates developer experience through structured commit practices, rich contextual information, and AI-powered automation.

What is ACCID Git?

ACCID Git combines the best practices of Conventional Commits and Atomic Commits into a unified workflow that makes your Git history more valuable, searchable, and maintainable.

Core Principles

Principle Description Benefit
Atomic Each commit represents a single logical change Clean git bisect, easy reverts, clear history
Conventional Follows structured format with standard types Automated changelogs, semantic versioning
Consistent Uniform format across all commits Predictable structure, easier parsing
Immutable Commits describe completed work Stable history, reliable archaeology
Durable Rich context (URIs, issue IDs, tags) Long-term maintainability, better debugging

Key Features

1. Structured Commit Messages

ACCID uses a powerful commit message format that captures not just what changed, but where and why: 

#123 [auth::services] feat: implement OAuth 2.0 login

- [auth::services::AuthService] add OAuth provider integration
- [auth::controllers] add /oauth/callback endpoint
- [auth::models::User] add oauth_provider field

Implements standard OAuth 2.0 authorization code flow with PKCE.

2. Resource URIs

Instead of vague file paths, ACCID uses logical resource identifiers that pinpoint exactly what changed in your codebase:

  • [auth::services::AuthService] - Clear module path
  • [apps::gate::middleware] - Monorepo support
  • [libs::pixel::components] - Library changes

3. Automation-Friendly Structure

ACCID commit messages are intentionally structured so humans, scripts, and AI-assisted tooling can generate, validate, parse, and review them consistently.

4. Issue Tracking Integration

Link commits directly to issues for complete traceability: 

#JIRA-123 [api] fix: resolve rate limit edge case
#456 [auth] feat: add multi-factor authentication

5. Branching Strategy

ACCID pairs best with trunk-based development and short-lived topic branches: keep main protected and releasable, branch only for focused work, and merge through review after automated checks pass.

The full branching guidance — including alternatives in the wild, lifecycle diagrams, workflow mapping, and protection rules — lives in the ACCID Branching Strategy.

Why ACCID Git?

For Developers

  • Less cognitive load - AI generates messages, you just review
  • Better context - URIs make it clear what changed
  • Easier debugging - Rich commit history helps track down issues
  • Cleaner rebases - Atomic commits make rebasing painless

For Teams

  • Consistent style - Everyone follows the same format
  • Better code review - Clear commit messages aid reviews
  • Automated workflows - Enable changelog generation, release notes
  • Knowledge preservation - Context survives long after code is written

For Projects

  • Professional history - Commit log is documentation
  • Easier onboarding - New contributors understand changes
  • Better analytics - Track what changes, where, and when
  • Compliance ready - Full traceability for audits

ACCID Git Workflow

ACCID can be adopted manually first, then automated as the repository matures. The workflow is:

  1. Make one coherent change.
  2. Review the diff and identify the affected resource URI.
  3. Write an ACCID or Conventional Commit message according to repository policy.
  4. Run tests and checks before review.
  5. Merge through protected branch rules.

Comparison with Other Standards

Feature Conventional Commits ACCID Git
Structure type(scope): message type: message with URIs
Scope granularity Module name Full resource URI path
Body format Free-form text Structured bullets with URIs
Issue linking In footer In header (#id)
Monorepo support Good Excellent (app:: prefix)
AI generation Limited Native support
Context preservation Good Excellent (URIs + tags)

Commit Message Format Options

ACCID is the recommended default for high-signal histories, especially in monorepos or projects where commits need to preserve rich context. Conventional Commits are also acceptable when a repository prioritizes ecosystem compatibility, semantic-release tooling, or simpler contributor onboarding.

Format Best for Example
ACCID Durable, resource-aware Git history with structured body bullets #123 [auth] feat: implement OAuth login
Conventional Commits Broad tooling compatibility and lower-friction contribution flows feat(auth): implement OAuth login

The full syntax for both formats lives in the ACCID Commit Specification.

Getting Started

  1. Choose the repository default. Use ACCID for high-signal durable history or Conventional Commits for ecosystem compatibility.
  2. Define resource URI conventions. Decide how app, library, feature, class, and function boundaries map to commit URIs.
  3. Document branch policy. Prefer trunk-based development, or document a disciplined environment-promotion exception.
  4. Add review and CI gates. Protect the integration branch with required checks and review.
  5. Automate later. Add commit templates, hooks, CI validation, or dedicated tooling once the human workflow is understood.

Learn More