Version Control & Code Review

Every change is reviewable, and architecture rules fail the pull request instead of slipping into release.

Clay illustration of branching and code review
Version Control & Code Review featured graphic

How it works

A left-to-right map of the work. Ports stay on fixed sides so the edges do not cross more than they have to. Pan or pinch if you want a closer look.

The usual problem

  • Feature work lands on main with a Slack ping and no review.
  • Style is enforced by whoever happens to look at the diff.
  • Handover later means reconstructing history from memory.

How I approach it

  • Feature-based development: one feature, one branch, one reviewable pull request.
  • The internal lint package is enforced in review, so architecture is not optional.
  • Rebase keeps the branch current. Cherry-pick when another line needs one commit, not the whole feature.

Process

  1. 01

    Feature

    Work is scoped as one feature. One feature, one branch — not a dump onto main.

  2. 02

    Branch

    A feature branch off main. Rebase onto main so the pull request stays current.

  3. 03

    Review

    A pull request with a human review. The lint package fails architecture rules on the PR.

  4. 04

    Land

    Merge to main so it stays releasable. Cherry-pick onto another line if a release needs that commit without the rest of the feature.

Stack and tools

GitHubFeature-based branchesRebaseCherry-pickPull-request reviewCustom Flutter lint

Proof from real work

Kadipay and MDBriefcase

Sazim mobile department lead, reviewing the team’s PRs

Feature-branch review with the internal lint package enforced on the PR.

Open the case study

What you get

  • A branching and review convention the team can keep
  • Lint running as part of review, not a local habit

How risk stays down

  • The client sees every change through pull requests.
  • Clean history makes handover possible without a war-room week.

Questions agencies ask