原文链接：
大团队的 Git 工作流往往不是单纯的分支模型问题。
当研发规模变大后，真正难的是把这些事情连起来：
字节这类研发设施实践的重点在于，Git 流程要被平台化承接，开发者日常看到的是 MR、检查、权限、发布单，底层才是分支与仓库。
团队小时候，大家在群里说一声就能协作。
团队变大后，如果没有平台规则，分支命名、评审要求、合并方式、发布流程都会逐渐分裂。
一个需求可能同时改客户端、服务端、平台工具、配置仓库。
如果每个仓库规则不同，跨仓库联调和发布就会变得不可控。
PR / MR 只要能点合并，团队就会倾向于快速合入。
如果 CI 结果、代码所有权、风险提示没有进入合并路径，Review 很容易只剩一个批准动作。
团队规范不要只停留在文档里，要尽量变成平台动作：
大团队需要区分：
这些权限最好和代码所有权、服务负责人、值班角色绑定。
CI、lint、单测、安全扫描、包大小、兼容性检查，不应只是“看一眼”。
它们要成为合并前的明确放行规则，失败时要能定位到负责人。
跨仓库变更至少要有一个统一的需求号、发布单或变更单，把多个 MR 关联起来。
这样 Review、测试、发布和回滚时才知道这些变更属于同一件事。
当团队超过几十人后，Git 工作流的成败主要取决于三件事：
只讲“我们用 Gitflow”或“我们用主干开发”是不够的。
字节这类实践适合放在团队协作和 GitHub 工程治理章节里，作为一个提醒：