1. 版本控制系统到底在管什么：从“文件命名地狱”说起
做任何带协作性质的项目，最先崩掉的往往不是技术方案，而是文件管理。我见过太多团队在项目中期陷入这样的状态：共享目录里躺着“最终版”“最终版2”“最终版_真的最终”“最终版_改完这版就发”，谁也不敢删，谁也不知道哪个是当前有效版本。Arcade Academy 把版本控制单独拎出来作为一节，本质上就是在解决这个问题——它管的不是代码，而是每一次变更的历史轨迹，让你随时能回答三个问题：谁改的、改了什么、为什么改。
版本控制系统（Version Control System，下文简称 VCS）的核心价值可以用一句话概括：把“覆盖式保存”变成“增量式记录”。传统做法是每次修改都另存一份完整文件，磁盘里堆满副本，差异靠人眼比对；VCS 则记录每次变更的差异（diff）和元信息（作者、时间、说明），需要时能把任意历史版本完整还原出来。这个差别就像记账：前者是每天拍一张钱包照片，后者是记流水账，后者才能算出钱花在哪了。
对 Arcade Academy 这类以项目实训为主线的学习场景来说，VCS 的意义还要更重一层。学员在练习中频繁试错，如果没有版本控制，一次误删或一次失败的实验就可能让几小时的工作归零；有了版本控制，最坏情况也只是回退到上一个提交点。更重要的是，提交历史本身就是一份学习档案——你三个月后回看自己当时的提交说明，能清楚看到思路是怎么演进的。这也是为什么这一节不是可选内容，而是所有后续协作环节的地基。
适合读这篇内容的人很明确：刚接触项目协作、还在用“复制文件夹”管理版本的新手；带学员做实训、需要一套统一版本管理规范的导师；以及已经会用基础命令、但想搞清楚分支策略和冲突处理的进阶者。下面我会按“为什么这么设计—核心概念怎么理解—完整实操怎么走—出问题怎么查”的顺序展开，中间穿插我自己踩过的坑和带人时反复强调的细节。
2. 整体设计思路：为什么是“分布式”而不是“集中式”
2.1 集中式与分布式的取舍逻辑
版本控制系统分两大流派：集中式和分布式。集中式的代表是 SVN 那一类，所有历史记录存在一台中央服务器上，每个人本地只有当前工作副本，提交和查看历史都要联网。分布式的代表是 Git，每个人本地都有一份完整的仓库副本，包含全部历史，提交、查看日志、切换分支都在本地完成，只有同步时才需要网络。
Arcade Academy 选择分布式方案，理由很实际。第一，实训场景网络条件不可控，学员在教室、宿舍、通勤路上都可能干活，本地有完整历史意味着断网也能提交、能回退、能对比，不会因为连不上服务器就卡住。第二，分布式天然支持“先本地折腾，折腾好了再同步”，学员可以放心大胆地做实验，本地提交几十次也不影响别人，最后整理成干净的提交再推上去。第三，分布式方案的分支成本极低，创建和切换分支几乎是瞬间完成的，这对“每个功能开一个分支”的协作模式是刚需。
集中式也不是没有优点，它的权限模型更直观，中央仓库就是唯一真相源，适合对审计要求极高的场景。但在教学和中小型协作里，这些优势抵不过分布式带来的灵活性和容错性。我个人的判断标准很简单：如果团队成员需要在离线状态下继续工作，或者需要频繁做实验性修改，就选分布式；如果团队规模很大、流程高度固化、需要严格的中央管控，集中式才值得考虑。
2.2 三层结构：工作区、暂存区、仓库
理解分布式 VCS 的关键，是搞清楚它的三层结构。很多人用了一年还是稀里糊涂，就是因为没把这三层的关系理顺。
- 工作区（Working Directory）：你眼睛能看到、手能直接改的那些文件，就是工作区。它是从仓库里“检出”出来的一份可编辑副本。
- 暂存区（Staging Area / Index）：一个中间缓冲区，用来挑选“这次提交要包含哪些改动”。你可以改了十个文件，但只把其中三个放进暂存区，提交时就只记录这三个。
- 本地仓库（Local Repository）：真正存放所有历史提交的地方，每次提交都会在这里生成一个不可变的记录。
这个设计的精妙之处在于暂存区。没有它的话，你只能“全量提交”或“逐个文件提交”，前者容易把调试代码、临时文件混进去，后者又太琐碎。有了暂存区，你可以把一次逻辑相关的改动挑出来组成一个干净的提交，把无关的改动留在工作区继续处理。这就是为什么提交前要先“添加”再“提交”——添加的动作本质上是“挑选”。
我用一个生活化的类比来解释：工作区是你正在炒的菜，暂存区是装盘准备上桌的那一份，仓库是已经端上桌、拍过照存档的成品。你可以锅里炒着三道菜，但只把其中一道装盘上桌；上桌的菜会被记录在案，锅里的还可以继续调整。这个类比我带新人时用了很多次，基本一遍就能讲明白。
2.3 提交对象的链式结构
再往深一层看，每次提交在底层是一个对象，包含三样东西：一棵指向当前文件快照的树、一个指向父提交的指针、以及作者和说明等元信息。多个提交通过“父指针”串成一条链，这就是所谓的提交历史。分支本质上只是一个指向某个提交的可移动指针，切换分支就是移动这个指针。
理解这一点非常重要，因为它解释了很多看似反直觉的现象。比如“为什么创建分支这么快”——因为它只是新建一个指针，不复制任何文件。“为什么合并会产生新提交”——因为合并要把两条链重新接起来，需要一个新的提交来记录“这两条历史在这里汇合了”。“为什么回退历史要小心”——因为如果已经同步给别人，改写历史会让别人的本地副本和远端对不上。这些后面都会展开，这里先埋个伏笔。
3. 核心概念逐个拆解：别被术语吓住
3.1 仓库初始化与首次提交的完整动作
拿到一个新项目，第一步是把它变成受版本控制的仓库。标准动作是在项目根目录执行初始化命令，这会在目录下生成一个隐藏的元数据目录，所有历史记录都存在里面。这个隐藏目录就是仓库的“大脑”，删掉它等于抹掉全部历史，所以千万别手滑。
初始化之后，第一件事是配置身份信息——提交记录里要写明是谁改的。这个配置分全局和仓库级两种，全局的对所有项目生效，仓库级的只对当前项目生效。实训场景里我建议每个项目单独配置，因为学员可能同时参与多个项目，用不同的署名更清晰。
# 初始化仓库 git init # 配置当前项目的提交身份（仓库级） git config user.name "某开发者" git config user.email "dev@example.com" # 查看当前生效的配置 git config --list配置完身份，就可以做首次提交了。首次提交前要先看看有哪些文件待纳入管理，用状态查看命令能看到“未跟踪文件”列表。这里有个关键动作：创建忽略规则文件。项目里总有些文件不该进仓库，比如依赖包目录、编译产物、本地环境配置、日志文件。这些文件体积大、频繁变动、且能从源码重新生成，提交进去只会污染历史。忽略规则文件里一行写一个匹配模式，支持通配符。
# 典型的忽略规则示例 node_modules/ dist/ *.log .env.local .DS_Store注意：忽略规则只对“尚未被跟踪”的文件生效。如果一个文件已经被提交过，之后再写进忽略规则是不起作用的，必须先把它从跟踪列表里移除，再提交一次移除记录。
首次提交的完整流程是：查看状态确认文件清单 → 添加要跟踪的文件到暂存区 → 再次查看状态确认暂存内容 → 写提交说明并提交。这个“添加前看一次、提交前再看一次”的习惯，能挡掉大量误提交。我带人时要求每个人前两周都必须严格执行这两次检查，养成肌肉记忆后再简化。
3.2 提交说明怎么写才算合格
提交说明是版本控制里最容易被敷衍、又最影响长期可维护性的东西。我见过大量“修改”“更新”“fix”这种说明，三个月后连作者自己都看不懂当时改了什么。合格的提交说明应该让一个不了解上下文的人，只看说明就能判断这次改动的影响范围。
我的写法是一行标题加一段正文的结构。标题控制在五六十个字符以内，用祈使句描述“这次提交做了什么”，比如“修复登录表单在空输入时的校验遗漏”。正文部分说明“为什么改”和“改动的关键点”，如果关联了某个任务编号也写进去。标题和正文之间空一行。
修复登录表单在空输入时的校验遗漏 原校验逻辑只在失焦时触发，用户直接点击提交按钮会绕过校验。 改为提交时统一触发一次全量校验，并补充了对应的边界用例。 关联任务：A-1024这里有个实操心得：提交要小而聚焦。一次提交只做一件事，不要把“修 bug”和“改格式”混在一起。小提交的好处是回退时精准——如果某次改动引入了问题，你可以只回退那一个提交，而不必牵连无关改动。我见过有人攒了一周的改动一次性提交，结果出问题时只能整体回退，一周工作白费。这个教训值得每个人记住。
3.3 查看历史与对比差异的正确姿势
历史查看命令是日常用得最频繁的之一。基础用法是列出提交列表，每条包含提交标识、作者、时间和说明。但默认输出信息量有限，我通常加几个参数让它更好用：单行显示每条提交、用图形化方式展示分支合并关系、给提交标识加上简短缩写。
# 单行 + 图形化 + 简写标识 git log --oneline --graph --decorate # 查看某个文件的历史变更 git log --oneline -- path/to/file # 查看某次提交的具体改动 git show <commit-id>对比差异是另一个高频操作。工作区和暂存区对比、暂存区和最新提交对比、两个提交之间对比，这三种对比覆盖了绝大多数场景。我特别想强调一个容易混淆的点：“已暂存”和“未暂存”是两个不同的对比维度。改了文件但没添加，差异出现在“工作区 vs 暂存区”；添加了但没提交，差异出现在“暂存区 vs 最新提交”。搞清楚这个，排查“为什么我改了却没提交上去”这类问题时就不会抓瞎。
# 工作区 vs 暂存区（还没添加的改动） git diff # 暂存区 vs 最新提交（已添加待提交的改动） git diff --staged # 两个提交之间对比 git diff <commit-a> <commit-b>3.4 撤销操作的三个层次
撤销是新手最容易慌的环节，因为不同阶段的撤销用的命令完全不同，用错了可能丢数据。我把它分成三个层次，按“改动走到哪一步”来选命令。
第一层，改动还在工作区、没添加：直接丢弃工作区的修改，让文件回到上次提交的状态。这个操作不可恢复，因为改动从未被记录过，所以执行前一定要确认。
第二层，改动已添加进暂存区、没提交：把它从暂存区撤出来，改动本身保留在工作区。这相当于“反添加”，文件内容不变，只是不再被本次提交包含。
第三层，改动已提交：这就涉及历史操作了。如果只是最近一次提交写错了说明或漏了文件，可以用“修补”方式重做最近一次提交；如果要回退到更早的提交，可以用“重置”把当前分支指针移到目标提交。重置又分三种模式，区别在于对工作区和暂存区的处理方式，这个后面在问题排查里详细讲。
# 第一层：丢弃工作区改动（谨慎） git restore path/to/file # 第二层：从暂存区撤出，保留工作区改动 git restore --staged path/to/file # 第三层：修补最近一次提交（改说明或补文件） git commit --amend注意：已经同步到远端的提交，不要用重置去改写历史。改写会让本地和远端的历史分叉，后续同步会非常麻烦。这种情况应该用“反向提交”的方式，即新建一个提交来抵消之前的改动，历史保持只增不改。
4. 分支与协作：把“并行开发”真正跑起来
4.1 分支模型的选型与理由
分支是分布式版本控制最强大的能力，但也是最容易被用乱的地方。常见的问题有两种：一种是从不建分支，所有人挤在一条线上改，冲突不断；另一种是分支建得满天飞，命名混乱，没人知道哪个分支是活的。
Arcade Academy 的场景适合一套轻量的分支模型，我把它总结为“一条主线加短生命周期功能分支”。主线分支始终保持可运行、可演示的状态，任何时刻检出主线都应该能跑起来。每个功能或修复从主线拉出独立分支，开发完成后合并回主线，合并后立即删除该分支。这个模型的好处是主线永远干净，功能分支生命周期短、合并冲突小。
为什么不推荐更复杂的分支模型？因为复杂模型（比如同时维护开发线、预发线、发布线多条长期分支）适合有专职发布流程的团队，对实训场景来说是过度设计。分支越多，合并路径越复杂，出错的概率越高。能用简单模型解决的问题，不要引入复杂模型，这是我带项目一贯的原则。
分支命名我要求统一格式：类型前缀加简短描述，比如功能类用feat/开头，修复类用fix/开头，文档类用docs/开头。这样一眼就能看出分支用途，也方便后续按前缀批量清理。
# 创建并切换到新分支 git switch -c feat/login-validation # 查看所有本地分支 git branch # 切换回主线 git switch main # 合并完成后删除功能分支 git branch -d feat/login-validation4.2 合并与变基：两种整合方式的本质区别
把功能分支的改动整合回主线，有两条路：合并和变基。这两者的区别是新手最常问的问题，我用一个类比讲清楚。
假设主线历史是 A→B→C，你从 B 拉出分支做了 D→E，期间主线又前进了 F。合并的做法是新建一个合并提交 M，它有两个父提交（E 和 F），历史图形状是一个分叉再汇合的菱形。变基的做法是把 D→E 这两个提交“摘下来”，重新接到 F 后面，变成 F→D'→E'，历史是一条直线。
合并保留了真实的开发时序，能看出“这两条线是并行开发的、在这里汇合”；变基让历史更线性、更整洁，但改写了提交的父指针，等于生成了新的提交（标识会变）。选择标准很明确：如果分支已经同步给别人、别人可能基于它继续工作，用合并；如果是自己本地还没同步的功能分支，想保持主线历史整洁，用变基。一条铁律：不要对已经同步的公共分支做变基。
# 在功能分支上，把主线的更新变基过来（保持线性） git switch feat/login-validation git rebase main # 或者切到主线，把功能分支合并进来（保留分叉） git switch main git merge feat/login-validation变基过程中如果遇到冲突，处理完冲突后要继续变基流程，而不是提交。这个细节很多人第一次会搞错，以为解决冲突后直接提交就行，结果变基卡在半路。正确做法是解决冲突、添加文件、然后执行“继续变基”命令。
4.3 冲突的本质与手工解决流程
冲突不是错误，是版本控制的正常现象。它的本质是：两个分支对同一文件的同一区域做了不同修改，系统无法自动判断该保留哪个。注意关键词是“同一区域”，如果两个人改的是同一文件的不同位置，系统能自动合并，不会冲突。
冲突发生时，系统会在文件里插入冲突标记，把两个版本的内容都保留下来，用分隔线隔开。你的任务是手工编辑这个文件，删掉标记，留下最终想要的内容。处理完所有冲突文件后，添加并提交，合并流程就完成了。
<<<<<<< HEAD 当前分支的版本内容 ======= 要合并进来的分支的版本内容 >>>>>>> feat/login-validation解决冲突的实操要点：第一，先理解两边的改动意图，不要盲目选一边，很多时候需要把两边的内容融合；第二，处理完用差异对比命令再检查一遍，确认没有残留的冲突标记；第三，如果冲突文件很多，可以先用状态命令列出所有冲突文件，逐个击破，别漏。
提示：冲突标记里的
HEAD指的是你当前所在分支的版本。合并时当前分支是接收方，变基时当前分支是被移动的一方，理解这个方向能避免选错内容。
4.4 远端协作的基本闭环
多人协作离不开远端仓库。基本闭环是：克隆远端仓库到本地 → 本地开发提交 → 拉取远端最新 → 推送本地提交。这个闭环里最容易出问题的是“拉取”和“推送”的顺序。
推送前必须先拉取，这是铁律。因为如果远端已经有别人的新提交，你直接推送会被拒绝（系统不允许覆盖别人的工作）。拉取会把远端的新提交合并到你本地，如果产生冲突就在本地解决，解决完再推送。这个顺序保证了远端历史只增不改，每个人的工作都不会被覆盖。
# 克隆远端仓库 git clone <repository-url> # 拉取远端最新（合并方式） git pull # 拉取远端最新（变基方式，保持线性） git pull --rebase # 推送本地提交 git push我个人的习惯是拉取时默认用变基方式，这样本地历史保持线性，提交图看起来清爽。但这有个前提：只对自己尚未推送的本地提交做变基。如果本地提交已经推送过，变基会改写远端历史，那就不能用了。这个边界要分清楚。
5. 实操全流程：从零到一次完整的协作提交
5.1 环境准备与仓库搭建
假设现在要为一个实训项目搭建版本管理环境。第一步是确认本地已经装好版本控制工具，用版本查询命令验证。然后创建项目目录，进入目录执行初始化。初始化后立刻配置身份信息和忽略规则，这两个动作要在第一次提交之前完成，否则第一次提交就会带上错误的署名或多余的文件。
# 验证工具已安装 git --version # 创建项目目录并进入 mkdir arcade-project && cd arcade-project # 初始化仓库 git init # 配置身份 git config user.name "某开发者" git config user.email "dev@example.com"忽略规则文件的内容要根据项目类型来定。前端项目重点忽略依赖目录和构建产物；后端项目重点忽略本地配置和日志；通用的是忽略系统生成的隐藏文件。写完后用状态命令确认，应该只看到源码文件和忽略规则文件本身待跟踪。
5.2 首次提交与远端关联
首次提交前，把源码文件添加到暂存区，再次查看状态确认清单无误，然后提交。提交说明写清楚“初始化项目结构”。接着在远端创建一个空仓库，把本地仓库和远端关联起来，推送首次提交。
# 添加所有源码文件 git add . # 确认暂存内容 git status # 首次提交 git commit -m "初始化项目结构，添加基础配置与忽略规则" # 关联远端并推送 git remote add origin <repository-url> git push -u origin main-u参数的作用是把本地分支和远端分支建立跟踪关系，之后直接git push和git pull就会默认操作对应的远端分支，不用每次指定。这个参数第一次推送时加上，后面就省事了。
5.3 功能分支的完整生命周期
现在要开发一个登录校验功能。标准流程是：从主线拉出功能分支 → 在分支上开发并分多次小提交 → 开发完成后切回主线 → 拉取远端最新 → 合并功能分支 → 推送 → 删除功能分支。
# 从主线拉出功能分支 git switch -c feat/login-validation # 开发过程中分多次提交 git add src/login.js git commit -m "添加登录表单基础校验逻辑" git add src/login.js tests/login.test.js git commit -m "补充空输入边界校验与对应测试用例" # 切回主线，同步远端 git switch main git pull --rebase # 合并功能分支 git merge feat/login-validation # 推送并清理分支 git push git branch -d feat/login-validation这个流程里我特别想强调“分多次小提交”。上面例子里两个提交分别对应“基础逻辑”和“边界补充”，逻辑清晰、粒度合适。如果合成一个大提交，将来想单独回退边界校验那部分就做不到。小提交是给自己留后路，不是形式主义。
5.4 一次冲突的现场处理记录
假设合并时登录文件产生了冲突。先看状态命令列出冲突文件，打开文件能看到冲突标记。假设一边是“失焦时校验”，一边是“提交时校验”，我的处理是把两边融合：失焦时做一次轻量提示，提交时做一次全量拦截。编辑完删掉所有标记，保存，添加，提交。
# 查看冲突文件 git status # 编辑冲突文件，融合两边逻辑后 git add src/login.js git commit -m "合并登录校验分支，融合失焦提示与提交拦截逻辑"处理完后再用差异对比命令复查一遍，确认没有残留的冲突标记。这个复查动作我强烈建议养成习惯，因为冲突标记残留是极其隐蔽的 bug 来源——代码能跑，但行为诡异，排查起来非常费劲。
6. 常见问题与排查技巧实录
6.1 提交错了怎么补救：三种场景对照
| 场景 | 现象 | 处理方式 | 风险提示 |
|---|---|---|---|
| 说明写错或漏文件，未推送 | 最近一次提交不完整 | 修补最近一次提交 | 仅限未推送的提交 |
| 提交到了错误的分支，未推送 | 提交出现在不该出现的分支 | 在正确分支上拣选该提交，再重置错误分支 | 拣选时注意冲突 |
| 已推送的提交要撤销 | 远端已有错误记录 | 新建反向提交抵消改动 | 不要改写已推送历史 |
修补最近一次提交是最常用的补救手段。改完文件或改完说明后，用修补参数重新提交，会覆盖最近一次提交而不是新增。这里的关键是只对未推送的提交用修补，因为修补本质上是改写历史，已推送的提交被改写会导致本地和远端分叉。
拣选（cherry-pick）是另一个实用技巧：把某个分支上的特定提交“摘”到当前分支。场景是提交到了错误分支，但内容是对的。先在正确分支上拣选那个提交，再回到错误分支把它重置掉。拣选时可能产生冲突，处理方式和普通合并一样。
6.2 误删与误改的找回路径
最让人心跳加速的场景是误删文件或误改内容后提交了。好消息是，只要曾经提交过，内容就还在仓库里，能找回来。路径有两条：如果删除或修改发生在最近一次提交，直接从上一个提交里检出该文件即可；如果发生在更早的提交，先用历史查看命令找到包含正确内容的那个提交，再从那个提交里检出文件。
# 从上一个提交恢复被删文件 git restore --source=HEAD~1 path/to/deleted-file # 先找到包含正确内容的提交 git log --oneline -- path/to/file # 从指定提交恢复 git restore --source=<commit-id> path/to/file还有一个更极端的情况：文件从未提交过就被删了。这种情况版本控制帮不上忙，因为系统只记录提交过的内容。这也是为什么我反复强调“小步频繁提交”——提交越频繁，未记录内容的窗口越小，丢失风险越低。
6.3 历史查看的几个高阶用法
基础的历史查看只能看到提交列表，但排查问题时往往需要更精细的查询。按文件查历史能看出某个文件被谁在什么时候改过；按内容查历史能找出某行代码是哪次提交引入的；按作者查历史能快速定位某个人的改动范围。这几个用法在排查“这行奇怪的代码是谁写的、为什么写”时特别管用。
# 查看某文件的变更历史 git log --oneline -- path/to/file # 逐行追溯某文件的每行来源提交 git blame path/to/file # 按提交说明关键词搜索 git log --oneline --grep="登录"逐行追溯（blame）这个命令名字听起来像甩锅工具，但它的正确定位是“考古工具”。看到一段看不懂的逻辑，用它查出引入的提交，再看那次提交的说明和完整改动，往往就能理解当时的意图。我带人排查历史遗留问题时，第一步永远是逐行追溯加查看提交说明。
6.4 我踩过的坑与带人时的高频错误
第一个坑：在错误的分支上开发。新手经常忘了切换分支，直接在主线上一通改，提交后才发现。预防办法是每次开始工作前先看一眼当前分支，养成“开工先看分支”的习惯。已经发生了就用拣选补救，别慌。
第二个坑：忽略规则写得太晚。依赖目录已经被提交进去了，再写忽略规则不生效，仓库体积暴涨。补救办法是先把这些文件从跟踪列表移除（保留本地文件），提交移除记录，之后忽略规则才生效。
# 从跟踪列表移除但保留本地文件 git rm -r --cached node_modules/ git commit -m "移除误提交的依赖目录，补充忽略规则"第三个坑：拉取时产生大量冲突。根源是功能分支活得太久，和主线偏离太远。预防办法是功能分支短生命周期，每天至少同步一次主线更新到功能分支，让冲突尽早暴露、小步解决。冲突拖得越久越难处理，这是铁律。
第四个坑：提交说明写“update”。这个错误的代价在三个月后才显现——回看历史时完全不知道每次提交干了什么。我的建议是把提交说明当成写给未来自己的信，写清楚“做了什么、为什么做”，多花三十秒，省下未来半小时。
6.5 团队协作的规范约定清单
带团队做实训时，我会在项目启动阶段就把下面这些约定写进项目说明文档，避免后期扯皮。
- 主线分支保护：不允许直接向主线推送，所有改动必须走功能分支加合并。
- 分支命名规范：类型前缀加简短描述，合并后立即删除。
- 提交粒度：一次提交只做一件事，说明写清楚动机。
- 同步频率：每天开工前先拉取远端最新，功能分支每天至少同步一次主线。
- 冲突处理：谁的分支谁负责解决冲突，解决后必须复查冲突标记。
- 忽略规则：项目初始化时就写好，新发现的忽略项及时补充。
这些约定看起来琐碎，但每一条都对应一个真实踩过的坑。规范的价值不在于约束，而在于让协作的预期一致——大家都知道该怎么做，就不用每次临时商量，效率自然就上来了。
7. 把版本控制用成习惯之后
我带过不少学员，刚开始都觉得版本控制是额外负担，提交说明随便写、分支懒得建。但坚持两三周之后，几乎所有人都会反过来感谢这套流程。原因很朴素：当你某次改崩了代码、靠回退十分钟就恢复如初时，当你回看提交历史理清自己思路演进时，当多人并行开发却几乎不打架时，你就再也回不去“复制文件夹”的时代了。
我个人的体会是，版本控制真正的门槛不在命令，而在习惯的建立。命令就那么十几个，一周就能背熟；难的是每次开工前看分支、每次提交前看状态、每次推送前先拉取这些动作变成肌肉记忆。我的建议是前两周刻意执行，哪怕项目很小也严格走流程，等习惯成型后再根据项目规模灵活调整。工具是死的，习惯是活的，把工具用成习惯，它才真正开始为你省事。
最后分享一个我常用的自查小技巧：每次提交前问自己三个问题——这次提交只做了一件事吗？说明能让三个月后的自己看懂吗？有没有把不该提交的文件混进来？三个问题都过了再按提交键，能挡掉九成以上的低级失误。这个习惯我保持了多年，至今仍然有效。
