2.5 版本控制：给工位装登记簿

2.5 版本控制：给工位装登记簿

本节摘要：版本控制装备的目标是不离开编辑器完成暂存、提交、追责与历史回看。本节先划清内置版本控制面板与增强插件的分工边界，再上架行内追责与提交图谱两件增强件，配置好暂存的部分提交与行级回滚，最后给出"哪些增强属于重复采购"的判断。登记簿立在工位上，每一次进出都有据可查。

木工房有个老规矩：工具借出要登记，谁拿的、什么时候还。代码这行当的登记簿就是版本控制系统，而编辑器里装的都是它的"前台窗口"。问题在于窗口装多了也乱：内置面板、增强插件、命令行三套界面管同一本账，不少人的工位上三者并存却只用得来一套。这一节是基础装备轮的收尾，把这本登记簿理清楚——正好接上前四节省下的力气，让"写、改、修"的成果都被台账接住。

适用场景与分工边界

先说清内置面板能干什么：暂存与提交、分支切换、简易的差异比对、基础的拉取推送——日常八成的版本操作它都覆盖。什么情况说明需要增强件了？三个信号：想知道"这行代码是谁、在哪个提交里改的"，得切到命令行敲指令；想在提交图谱上找一次合并的来龙去脉，图形工具得开外部应用；想在行内直接看到每一行的"作者标注"，没有现成入口。对上号的才装，对不上号的别囤。

增强件一：行内追责

第一件增强是版本控制增强套件（生态里最知名的即"给版本控制装上增压器"的那件），核心价值是把仓库元信息铺到编辑器里：

{
  "gitlens.currentLine.enabled": true,
  "gitlens.codeLens.enabled": true,
  "gitlens.hovers.currentLine.over": "line",
  "gitlens.blame.format": "${author|you} ${date} · ${message}"
}
​

行尾悬浮显示当前行的最后修改人与提交说明；文件头与函数头的透镜标注显示"最近谁动过这一段"。它把"追责"从一次操作变成一眼可见——读老代码时，看到某段实现上方标着一次重构提交，顺着提交说明往往能直接读懂当年的设计意图，这是读代码的捷径而不只是查锅的工具。

增强件二：提交图谱

第二件增强是仓库历史图谱：把分支、合并、提交画成一张可视化拓扑，配合"在历史中比较任意两次提交"的能力，回答"这次合并到底进了什么""这周上线了哪些改动"这类问题。开评审、做发布检查时，图谱比命令行输出的文本树直观一档。

暂存的部分提交与行级回滚

台账要细到什么粒度？答案是行。编辑器内置就支持：点开差异视图，单块、单行地暂存——一次改动里既有该提交的重构又有不该提交的调试残留时，把干净的部分单独暂存提交，脏的留下继续改。回滚同理，差异视图里可以按块丢弃未暂存的改动，不必整文件回退。这两招配合下面的确认配置，构成安全的提交流水线：

{
  "git.autofetch": true,
  "git.confirmSync": false,
  "git.enableSmartCommit": false,
  "scm.diffDecorationsGutterPattern": {
    "modified": "true"
  }
}
​

自动拉取保持本地台账不落后；同步不重复确认（个人仓库适用）；智能提交保持关闭——它会在没有暂存内容时自动暂存全部改动，对讲究提交粒度的工位是个坏默认值。

图 2-5：工作区改动的登记流转

台面实测：一次线上回溯

看这套台账的实战形态。某次上线后一处行为异常，怀疑是某次合并带进来的旧逻辑。流程：提交图谱上找到可疑合并点，点开"比较该合并前后"，差异清单里锁到目标文件；打开文件，行内追责显示这行最后修改于那次合并，提交说明写着"临时恢复旧分支兼容"；定位完成，回滚方案同步成形——整段过程没有离开编辑器。旧打法里"翻提交记录、切外部比对工具、命令行查历史"的连环切换被压缩成了图谱上的三次点击。

坑点提醒

坑一，追责变成点名工具。 行内标注的存在感太强会毒化协作氛围——它更适合用来理解代码演化，而不是在会上指着某行问罪。觉得碍眼可以把默认显示收窄到悬浮触发。坑二，增强套件全家桶化。 知名增强件附带大量功能（看板、工单集成、工作区管理），全开会明显加重启动负担；只开追责与透镜，其余在设置里关净——这也是第 6 章性能调校的预演。坑三，与平台集成插件的账号混乱。 增强件与代码托管平台的集成插件各存一份凭据，过期时间不同步；统一用平台官方的认证流程，少一套密码就少一处失联。

替代方案

最重的替代是独立的图形化版本控制客户端，功能最全，适合复杂的交互式变基；最轻的是纯命令行，服务器上没得选，本地也有人偏爱。编辑器内方案的独特价值在于"不切上下文"——追责、比对、提交都在写代码的同一个窗口里完成。三者不互斥，我的工位配置是：日常操作全在编辑器内，复杂变基开专用客户端，服务器维护用命令行。

常见疑问快答

问：增强件会不会拖慢编辑器？答：知名增强套件的功能开关很多，全开时确实可观。建议只开追责、透镜、历史这几路核心，看板与工单集成按需；第 6 章的运行时面板可以量化它的开销，用数据说话而不是凭感觉卸载。

问：行内追责在代码评审里怎么用才不伤感情？答：把它当“理解工具”而不是“问责工具”——看一段老实现时，追责信息告诉你它何时为何被写成这样；评审意见引用提交说明而非作者名字。工具中性，用法决定毒性，团队 leader 先示范正确用法最有效。

问：内置面板、增强件、命令行，三者日常怎么分工？答：日常的暂存提交推送全在内置面板；读代码时的追责与历史走增强件；复杂变基、大范围检索、脚本化操作交给命令行。三层各占一段使用频率曲线，谁也替代不了谁。

问：提交信息怎么写才对得起这套台账？答：把每条提交信息当成“未来的自己在检索”来写——说清为什么改，而不只是改了什么（差异视图已经回答了后者）。追责透镜展示的正是这行字，它写得越有信息量，整个台账的回溯价值就越高。

收束与第一轮升级收官

基础五件套至此配齐：补全、格式化、导航、调试、版本控制，输入、输出、移动、检修、归档的闭环成立。下一章开始第二轮升级——工位划出前端专区，网页三件套与框架装备进场。