my-git

Engineering Practices Decision Map

English

中文

Use this page to map your team’s current pain points to public engineering case studies and actionable guidance.

Start with Your Problem

Team Problem	Reference Cases	Corresponding Thematic Articles
PRs are too large, review costs are high	Google Code Review, Meta Sapling	Pull Request Best Practices, Stacked PR
AI generates large diffs, needs splitting	Google Code Review, Meta Sapling	AI Commit Splitting, AI Generated Code Review Example
Many PRs, main branch easily broken by combined changes	Shopify Merge Queue, Merge Queue Practice	Merge Queue
Fixed release windows, release branches, hotfix backporting	Microsoft Release Flow, Tencent Gitflow	Release Management, Gitflow
High-frequency deployment, need to break risks into daily releases	Slack Deploys, Netflix Spinnaker	Release Management
Repository is large, clone, checkout, status are very slow	Microsoft Scalar, Uber GitFarm	Large Repository Git Practices
Trunk-based development supporting large-scale collaboration	Google Trunk-Based Development, GitHub Flow Enterprise Practice	Trunk-Based Development, GitHub Flow
Multiple features in parallel, need to flexibly combine release scopes	Alibaba AoneFlow	Team Git Workflow Guide, Gitflow

Four Core Takeaways

1. Google’s Small CLs — Applied to Large AI Diffs

Google Code Review enforces small changes, clear intent, and long-term code health.

For AI-assisted development, the principle worth borrowing is how to split changes:

• Separate tests, behavioral changes, refactoring, and documentation into distinct CLs
• Each change should have a goal you can state in one sentence
• Reviewers can assess risk without needing to hold the full context in their heads
• Large features ship as a sequence of small, reviewable steps

Corresponding reading:

• AI Commit Splitting
• AI Generated Code Review Example
• Pull Request Best Practices

2. Shopify’s Merge Queue — Applied to High-Volume PR Teams

When PR volume is high, a single PR passing CI in isolation is not enough. The real risk is the combined state after several PRs land in quick succession.

Shopify’s experience shows where a Merge Queue earns its keep:

• Validating the combined state before it touches the main branch
• Reducing the chance of a broken main
• Giving developers visibility into failure reasons, queue position, and retry options
• Surfacing flaky tests and slow CI before they become everyone’s problem

Corresponding reading:

• Merge Queue
• Enterprise GitHub Workflow Stack

3. Microsoft Release Flow — Applied to Teams with Fixed Release Windows

Most business teams cannot ship to production on every merge. For them, release branches remain useful.

Microsoft Release Flow offers a clear model:

• The mainline absorbs daily development
• Release branches own the release window
• Only stability fixes go into a release branch — no new features
• Every fix must be backported to the mainline
• Every release must be traceable to a commit, tag, and release note

Corresponding reading:

• Release Management
• Team Git Workflow Guide

4. Meta Sapling — Applied to Stacked PRs

Large features, monorepos, and large AI diffs share a common failure mode: once a single change grows too large, reliable human review breaks down.

Meta Sapling’s approach to commit stacks translates into four practical rules:

• Use a commit stack to represent a sequence of small, incremental changes
• Every layer in the stack must be explainable on its own
• Later commits may depend on earlier ones — make those dependencies explicit
• Tooling should show developers the dependency graph and the history at a glance

Corresponding reading:

• Stacked PR for AI-Generated Changes
• AI Commit Splitting
• Large Repository Git Practices

Adoption Guidance

Don’t copy any single company’s workflow end-to-end.

A more reliable approach: answer these five questions first, then pull only the practices that fit.

1. What is the team’s sharpest pain point right now — review cost, release rhythm, main branch stability, large-repo performance, or AI-generated change risk?
2. Is CI fast enough to run on every PR?
3. Does the main branch need to be shippable at any time?
4. Are there fixed release windows?
5. Are there clear owners and a tested rollback path?

The clearer your answers, the easier it is to identify which practices from these case studies will actually land.

This site is open source. Improve this page.