Every guide is rooted in a real codebase, signed off by the maintainers who shipped it, and revisited when reality disagrees. Browse by topic.
Trunk-based, release branches, GitFlow - when each one earns its keep, and the warning signs you've outgrown it.
Templates that get reviewed, size limits that stick, and how to leave a comment that doesn't make someone defensive.
Contract tests, snapshot hygiene, killing flaky CI - patterns that hold up at 50 engineers and 50,000.
Semver in practice, changelogs your users actually read, and rollback drills that don't require a hero.
Onboarding new contributors, RFCs that ship, governance that scales without smothering momentum.
Post-mortems, redesigns, and the "we should have done this 6 months earlier" stories worth reading.
When to bump major, minor, or patch — and why SemVer is the wrong tool for services. Includes a consumer-first changelog format that people actually read.
A monorepo team is debating a major version bump. The API change in question is to an internal library — used by exactly two services, both owned by the same team, both deployed simultaneously. The "consumer" of the breaking change is them, this afternoon. Half the team says "it's a breaking change, that's major, that's the rule." The other half says "we control both sides, why are we burning a major version on something nobody else will ever…
No gatekeepers. The same workflow we document is the one we use to write the docs.
If a pattern only works in one stack, we say so. Most patterns here are older than your build tool.
Every guide is dated, versioned, and revisited. We retire patterns that haven't aged well, on purpose.
Found a pattern that worked? Disagree with an existing guide? Open a pull request, write up your story, or just add a sentence - the way we work is the way the docs grow.