ADR-002- Git Workflow

Status: Accepted

Date: June 2026

Context

Rundown requires a Git workflow that supports collaborative development while remaining simple to understand and maintain.

Two approaches were considered:

Git Flow
Trunk-Based Development

The selected workflow should support client projects, small engineering teams, and continuous deployment without introducing unnecessary complexity.

Decision

Rundown will adopt Trunk-Based Development.

All production code will live on the main branch.

Every feature, bug fix, documentation update, or maintenance task will be developed in a short-lived feature branch and merged into main through a Pull Request.

Workflow

main
  ↑
feature/navbar

feature/blog

feature/contact-form

feature/ecommerce

Each feature branch should:

Focus on a single objective.
Remain short-lived.
Be reviewed before merging.
Be deleted after merging.

Reasoning

Trunk-Based Development provides:

Simpler branch management
Faster development
Smaller Pull Requests
Fewer merge conflicts
Easier onboarding
Better support for continuous deployment

It aligns with Rundown's engineering philosophy of preferring simplicity unless additional complexity provides measurable value.

Alternatives Considered

Git Flow

Git Flow introduces additional permanent branches such as develop, release, and hotfix.

While useful for large organizations with complex release cycles, it adds unnecessary overhead for the size and nature of Rundown's projects.

Consequences

Positive

Cleaner workflow
Faster releases
Simpler repository structure
Easier onboarding
Reduced merge conflicts

Negative

Requires disciplined use of feature branches.
Developers must keep feature branches small and focused.

Review Criteria

This decision should be reviewed if:

The engineering team grows significantly.
Projects require long-lived release branches.
Multiple production versions need to be maintained simultaneously.

Until then, Trunk-Based Development remains the official Git workflow for Rundown.