一张图看懂：两个人、一个仓库、互不踩脚

三个地方，两个方向

两台电脑 + 一个中心仓库 + 一台生产服务器

只需要形成肌肉记忆的，是这三条

前面的原理都可以现查，这三条要不假思索。

这一页出现过的词

讲协作绕不开一批词。这里按人话说一遍，看完不用回头再查。带链接的几个，概念词典里有更细的一条。

构建（build）

把源代码打包成可运行成品的过程。它同时是一道免费体检：代码有低级错误，构建会直接报红失败。构建绿＝至少能跑起来，不代表逻辑全对。 细讲见词典《源码与生成物》

仓库副本（克隆）

每台电脑上那份完整的仓库拷贝，含全部历史。它是一张「照片」——拍摄时刻＝上次取最新的时刻；不主动取，它永远不会自己更新。 细讲见词典《代码仓库》

生产服务器

跑着正式系统、每天真实被使用的那台服务器。它按主干同步，是「主干就是生产」这句话的物理落点。 细讲见词典《部署》

取最新（pull）

一条命令：把平台上主干的最新内容取下来，更新我这台电脑的副本。开工第一动作，真正作用是给协作双方换上同一张最新地图。 细讲见词典《提交与推送》

主干（master / main）

仓库的主线，所有人的改动最终都汇入这里。服务器按它部署，所以主干的内容＝线上系统的来源。这也是「主干就是生产」的含义。 细讲见词典《分支》

合并请求（PR）

一份「我改了这些，请过目后并入主干」的申请单。页面上能看到全部改动对比、讨论区和合并按钮。它就是异步协作台。 细讲见词典《送审与合并》

合并（merge）

把分支上的改动正式并入主干的那个动作。合并后改动进入主干——但合并不等于上线，部署是独立的下一步。 细讲见词典《送审与合并》

审查（review）

合并前的人工过目。看的是机器管不了的四条：改动范围、口径一致、有无误伤、理解对不对。不挑语法——语法有构建管。 细讲见词典《送审与合并》

请求修改（Request changes）

审查的一种结论：「有问题，按我标在具体行上的意见改」。对方在同一分支改完再推，自动更新进同一份合并请求，不用新开。

唯一事实源

判断「现在系统到底是什么样」时，唯一算数的那份依据。约定：以平台上的主干为准——不以任何人的记忆、聊天记录、或某台电脑上的副本为准。

踩脚

两个人同时改同一处，一方把另一方的成果覆盖或搞乱。整套协作流程的设计目标，就是让踩脚在结构上不可能发生，而不是靠小心。

自动成立

指「不需要额外做任何事就天然为真」。说「对齐不是把代码放一起就自动成立的」——意思是：对齐要靠约定和动作持续维持，放一起只是前提。

代码实况

代码此刻真实的样子——打开代码看到的，而不是记忆里、聊天里、旧文档里说的样子。判断一律以实况为准。

机器

泛指每人自己那台电脑。「两台机器之间没有连线」＝双方从不直接互传文件，一切经由中间的仓库。

共管区

两条线都会碰到、动了会影响对方的区域：数据结构、对外接口、共用文档。规矩统一是「只增不改，要改先打招呼」。

各自为营只对代码成立，对文档不成立

代码有物理分区（一人一个目录，合并永不碰头）；共用文档是单个文件，两人同时写必然相撞。所以代码可以放手各干，文档必须约定「只有一个人写」。

断网也能干

因为副本是完整的（含全部历史），中间干活不需要联网。只有开工取和收工送两个时刻需要网络——这就是「各自为营」的技术底气。

爆炸半径管理

一项改动出错时，波及范围有多大、能不能控制住。分支的意义＝把爆炸半径压到零：合并之前，改动只存在于自己的分支上，对线上影响为零。

全员合并请求制

所有人（包括负责人）都走合并请求、没有任何人直推的模式——多人团队的标准形态。小团队常见的过渡期形态是：新加入者走合并请求，负责人保留直推，跑顺后再议。

对齐检测器

指合并请求页面的自动冲突检查：平台自动比对你的分支与最新主干，有冲突就标红提示。免费、自动、不需要任何人盯着。

这不是官僚，是成本账

流程取舍的标准不是「正规不正规」，而是哪种做法总成本更低。例：共用大文档约定一人写，比教会每个人处理几十万字的合并冲突，便宜一个数量级。