Git提交原理与版本库解析：三区流转、分布式版本控制和工作流

第一次带人看仓库，我问了个特别基础的问题：你敲下git commit那一瞬间，文件到底被存到哪儿去了？对方愣了几秒，说“存到 Git 里了吧”。这个回答不能算错，但基本等于没说。后来我发现，绝大多数人用 Git 三五年，仍然把 Git 当成一个“能上传代码的网盘”，所以他们会在合并冲突面前手足无措，会在误删分支后冷汗直流，会搞不懂为什么同事的仓库和自己的对不上。这些麻烦的根子，几乎都能追回到对工作流、分布式版本控制、版本库这三个基本概念的理解偏差上。

这篇是我打算写的 Git 基础系列第一篇，只谈概念，不堆命令。目标很明确：把 Git 的三个区域怎么流转、分布式到底“分布”了什么、版本库里那些目录和文件各管什么事，一次讲透。适合刚接触 Git 的新手，也适合用了很久但一直靠“记住命令”过日子的老手——后者往往更需要重新校准一遍底层模型。我会尽量用生活里的类比来解释抽象结构，同时把每个设计背后的“为什么”交代清楚，毕竟 Git 的命令可以查文档，但为什么要这么设计，文档通常懒得告诉你。

1. 三个区域与一条命令链：Git 到底把你的代码放在了哪里

1.1 工作区、暂存区、版本库：三个抽屉的分工

我习惯把 Git 的三个区域比作办公桌上的三个抽屉。工作区（Working Directory）就是你眼前这个能看见、能编辑的文件夹，你在这里改代码、删文件、加注释，所有动作都是“草稿”状态，Git 未必知道，也未必在意。暂存区（Staging Area，也叫索引 index）是第二个抽屉，你把想提交的改动一件件放进去，摆好顺序，相当于把要寄出的东西装进快递盒。版本库（Repository，就是那个.git目录）是第三个抽屉，东西一旦装进去封好，就有了编号、有了时间戳、有了不可篡改的记录。

这个比喻里最容易被忽略的一点是：三个抽屉之间不会自动同步。你在工作区改了十个文件，暂存区里可能一个都没有；你往暂存区放了三处改动，版本库里可能还是上一次提交的样子。很多人刚上手时的困惑——"我明明改了，怎么git status显示没变化"、"我提交了怎么服务器上没有"——本质上都是没意识到自己在跟三个独立的区域打交道。

还有一层：暂存区并不是一个“文件夹备份”，它记录的是路径到文件内容的映射关系，外加每个文件的元信息（大小、修改时间、inode 等）。这些元信息的存在是为了性能：git status判断文件有没有变，先看大小和 mtime，一致就直接跳过，不一致再算哈希比对内容。所以你偶尔会看到“touch 了一下文件，Git 就说它变了”的现象，那是元信息变了触发了重新比对，但比对完发现内容其实没变，最终不会产生差异。

1.2 一次 git commit 在内部走过的完整路径

把这条链路走一遍，你对 Git 的理解会立刻上一个台阶。假设你改了app.js，然后执行git add app.js。这一步 Git 做的事情远比“标记一下”复杂：它读取文件内容，在前面拼上头信息blob <字节数>\0，对整个字符串算一次 SHA-1（新版本仓库也支持 SHA-256），得到一个四十位的十六进制字符串。然后它检查.git/objects下有没有这个哈希对应的文件，没有就把内容压缩后存进去，文件名就是那个哈希。接着，它更新.git/index，把app.js这个路径指向刚算出来的哈希。

再执行git commit -m "..."。这一步 Git 先根据 index 里的路径和哈希，构造出目录树结构，写成一个tree 对象；然后构造一个commit 对象，里面记着这个 tree 的哈希、父提交的哈希、作者和提交者信息、时间戳、提交说明；最后，把当前分支的引用（比如refs/heads/main）指向这个新 commit 的哈希。整个过程中，你的原始文件从来没被“移动”过，被搬来搬去的只是内容和指针。

所以一条重要的认知是：commit 不是差异包，是快照。每次提交都对应一棵完整的目录树，只是 Git 用内容寻址加对象复用，让没变的文件在物理上只存一份。你git log -p看到的 diff，是 Git 在展示时现算出来的，不是存储格式。这个区别直接决定了后面很多行为：切分支为什么那么快、为什么历史可以任意跳、为什么仓库体积不会随提交次数线性膨胀。

1.3 暂存区为什么不是多余设计

新手最常见的抱怨是：为什么不能git commit直接提交所有改动，非要中间加一道git add？这不是历史包袱，是刻意设计。暂存区给了你在提交之前重新编排内容的能力。举个真实场景：你为了修一个线上 bug，顺手把旁边一段丑代码格式化了，还删了两行调试日志。这时候如果整体提交，code review 的人要在一堆无关改动里找那三行修复内容，评审效率直接崩掉。有了暂存区，你可以只git add那三行，先提一个干净的修复提交，剩下的格式化单独提一个style:提交。

更进一步，git add -p（部分暂存）能让你在文件内部按“块”选择，同一个文件的不同改动可以拆进不同提交。这个功能我第一次用的时候觉得很别扭，用了半年之后彻底离不开了——它把“提交”从“保存进度”变成了“讲故事”，一个提交讲一件事，历史读起来才顺畅。代价是你得多敲几次交互式确认，但换来的是半年后你自己回看git log时不需要猜“这次到底改了啥”。

还有个小细节值得记住：git add之后的文件如果被再次修改，暂存区里保留的仍是 add 那一刻的内容。这时候git status会同时显示“已暂存的更改”和“未暂存的更改”，git diff看的是工作区与暂存区的差异，git diff --cached（或--staged）看的才是暂存区与最后一次提交的差异。这两个命令搞混，是排查“我提交的东西怎么不对”这类问题的第一大原因。

2. 分布式版本控制的真实含义：本地那份完整历史值多少钱

2.1 集中式模型的日常与它的软肋

要理解分布式，得先想清楚它对比的是什么。集中式版本控制（典型代表是早期那批以服务端为唯一权威的工具）的模型很简单：仓库只有一份，放在中央服务器上，每个人检出的是一个工作副本，包含最新版本的文件，但不含历史。你想看三个版本之前的代码长什么样，得连服务器；你想提交，得连服务器；服务器维护窗口期，所有人都只能干等着。

这个模型在带宽紧张、磁盘昂贵的年代非常合理，它把存储成本压到了最低。但它的软肋也很明显：所有操作都被网络绑架。出差在高铁上想提交一个阶段性成果，做不到；想比较两个历史版本，得先把数据拉下来；服务器硬盘坏了又没有可靠备份，整个项目历史就没了。更隐蔽的问题是分支成本——在集中式模型里，分支通常体现为服务器上的一个目录副本，创建一个分支意味着复制整份代码，成本高到让人不敢随便开分支，于是所有人都挤在主干上改，冲突频发。

我在一个老项目里见过这种工作方式的后果：因为分支太贵，团队养成了“改完直接在主干上覆盖”的习惯，谁改坏了谁负责回滚，回滚靠的是手工备份的压缩包。那套流程下，没人敢做超过半天的重构，技术债越滚越大。后来迁到 Git，第一件事就是把“开分支”的成本降到零，团队的重构意愿肉眼可见地变强了。

2.2 克隆之后你手里到底有什么

git clone和“下载代码”是两件完全不同的事。克隆完成后，你的本地磁盘上有一份完整的版本库：全部历史提交、全部分支引用、全部标签、全部对象数据。这意味着断网状态下你能做几乎所有事情——查看任意历史版本、对比任意两个提交、创建分支、提交改动、合并分支、查看谁在什么时候改了哪一行。网络只在需要与他人交换数据时才登场。

这个特性的价值在几个具体场景里体现得特别明显。代码审查时，你可以把同事的分支拉下来，在本地慢慢看、慢慢跑测试、慢慢改，不需要占用任何服务器资源。排查线上问题时，你可以 checkout 到任意一个历史版本，本地复现，二分定位（git bisect）到底是哪次提交引入的问题，整个过程几十次 checkout 全部在本地完成，速度取决于磁盘而不是网速。做实验性重构时，你可以在本地开十个分支试十种方案，失败了直接删掉，服务器上什么痕迹都不留。

需要澄清一个常见误解：分布式不等于没有中央仓库。实际团队协作里，几乎都会指定一个“origin”作为共享的权威仓库，大家往上推、从上面拉。分布式的真正含义是“每个节点都持有完整数据”，而不是“不需要中心”。中心依然存在，但它从“唯一的数据源”降级成了“一个大家约定好的交换点”。这个身份变化很关键——中央仓库挂了，任何一个人的本地仓库都能立刻顶上去重建，数据不会丢。

2.3 离线提交与本地分支带来的工作方式变化

分布式对工作习惯的影响，比想象中深远。最直接的一条是：提交变成了纯本地行为。你可以在飞机上、在地铁里、在服务器维护期间，随时随地git commit，一次提交只写本地磁盘，几毫秒完成。提交频率因此可以大幅提高——不再是“攒一天然后推一次”，而是“做完一个小逻辑就提一次”。高频提交带来的好处是回滚粒度细、问题定位快，坏处是如果不管提交信息质量，历史会变成一堆“fix”“update”的垃圾。

第二条影响是分支的使用方式彻底变了。本地开分支几乎是零成本的（本质就是往.git/refs/heads/写一个四十字节的文件），所以你可以给每个想法都开一个分支，试完不满意直接删。我自己的习惯是，哪怕只是改一行配置，也开个分支，改完合并回去再删掉。这么做的理由很实际：主线永远保持随时可发布的状态，任何半成品都隔离在分支上。

第三条影响比较隐蔽：历史是可以被整理的。因为提交发生在本地、还没推给别人，你可以随意改写——合并几个零碎提交、修改提交信息、调整提交顺序、把误提交的大文件从历史里剔掉。一旦推送到共享仓库，这些操作就该停了，因为别人可能已经基于那些提交开始工作了。这条“本地随便改、推送要谨慎”的边界，是分布式协作里最重要的一条默契，也是新手最容易越界的地方。

2.4 分布式的代价：没有锁，只有约定

说完好处得说说代价，否则就是片面宣传了。集中式系统通常提供文件锁：我要改这个文件，先锁定，别人就改不了，冲突从源头上被避免。Git 没有这套机制，两个人可以同时改同一个文件的同一行，谁先推谁赢，后推的人必须先拉取、解决冲突、再推。

这个设计不是偷懒，是权衡的结果。锁机制在文件粒度上工作，适合二进制文件和大型资源文件，但对源代码来说代价太高——你锁了一个文件，别人可能只是想改里面另一个函数，却被迫等待。Git 选择了“允许并行修改，冲突在合并时解决”的路线，把冲突从“事前阻塞”变成了“事后处理”。代价是每个人都得会解决冲突，收益是并行度大幅提升。

与之配套的是约定文化。既然没有技术手段强制，那就靠流程约束：推送前先拉取、别对已推送的提交做变基、分支命名要有意义、提交信息要写清楚动机。这些东西 Git 本身不管，但团队不管就会乱。我见过最混乱的一个仓库，主干上同时存在三种命名风格的分支、几十个已经合并但没人删的僵尸分支、以及大量信息为空的提交——技术上完全合法，协作上是一场灾难。

3. 版本库的解剖：.git 目录里究竟躺着什么

3.1 HEAD、index、refs、objects 四个角色

把.git目录打开看一眼，大部分人会有点懵：一堆看不懂的目录和文件。其实核心角色只有四个。objects是所有数据的最终归宿——文件内容、目录结构、提交记录、标签，全部以对象形式压缩存储在这里，用哈希命名。refs存放各种引用，refs/heads/下每个文件就是一个本地分支，文件内容就是它指向的提交哈希；refs/tags/下是标签；refs/remotes/下是远程分支的本地快照。HEAD是一个指针的指针，通常内容是ref: refs/heads/main，意思是“我现在在 main 分支上”。index就是前面说的暂存区，二进制格式，记录路径到对象的映射以及文件元信息。

理解这四个角色的关系，能解释很多“诡异”现象。比如为什么git checkout切分支那么快？因为它只改了两样东西：HEAD的内容，以及把 index 和工作区同步成目标提交的树。几万个文件的项目切分支也就一两秒，因为没变动的文件根本不用碰。再比如为什么删掉一个分支后提交还在？因为分支只是一个指针文件，删指针不等于删对象，只要还有别的引用指向那条链（或者你记得哈希），数据就一直躺在objects里，等着被垃圾回收。

再补一个实用知识点：HEAD处于“分离”状态（detached HEAD）是什么意思？就是HEAD里直接写了一个提交哈希，而不是指向某个分支。这时候你做的提交不属于任何分支，切走之后就很难找回（除非记下哈希）。这个状态本身不可怕，查看历史、跑测试时经常需要，但千万别在分离状态下做正式开发。我见过有人在分离状态下写了半天代码，切回主线后发现改动“消失”了，其实是提交还在，只是没有分支指向它。

3.2 blob、tree、commit 三种对象的拼装关系

Git 的对象模型非常简洁，只有四种类型：blob、tree、commit、tag（annotated tag）。blob存文件内容，注意它不含文件名、不含路径、不含权限，纯粹是字节流。tree存一层目录结构，每一条记录包含模式（文件还是目录、是否可执行）、对象类型、哈希、名字。commit存一次提交的元信息：指向一个 tree、指向零个或多个父 commit、作者、提交者、时间、说明。

这个分层设计的妙处在于内容和名字彻底解耦。同一个文件在不同目录下出现，只要内容一样，就是同一个 blob，物理上只存一份。重命名一个文件，Git 层面其实是一次“删旧路径 + 加新路径”，但因为新路径指向的还是同一个 blob，存储开销几乎为零。你在git log --follow里看到的“重命名追踪”，是展示时通过内容相似度算出来的，不是存储时记录的。这也解释了一个经典困惑：为什么 Git 不记录重命名？因为它压根不需要记，内容寻址天然处理了这件事。

commit 之间的父子关系构成了一张有向无环图，而不是一条直线。合并（merge）产生的提交有两个父提交，这就是“分叉又汇合”的图形来源。理解这一点，你就明白为什么git log --graph画出来的线会分叉和汇合，也明白为什么有些操作需要指定“相对于哪个父提交”——因为合并提交确实有两个来路。

3.3 内容寻址：哈希不是校验码，是地址

很多人把哈希理解成“校验码”，用来验证数据没坏。这个理解不算错，但漏掉了关键的一半：在 Git 里，哈希同时是寻址方式。你要取一个对象，不是靠“第几个文件”“什么路径”，而是靠“算出它的哈希，去objects目录里按哈希找”。这就叫内容寻址。

内容寻址带来几个必然结果。第一，相同内容永远只存一份，天然去重，这也是为什么往仓库里放一堆重复的小文件不会让体积翻倍。第二，内容不可篡改，改一个字节，哈希全变，等于换了一个对象。第三，历史链自校验，因为 commit 对象里包含父提交的哈希，改动任何一个历史提交，它之后所有提交的哈希都会变，整条链对不上，立刻能发现。

第三点在协作场景下特别有价值。你拉下来的历史，和远端的历史，只要最新提交的哈希一致，就能确信中间每一个字节都没被动过。这也解释了为什么强推（force push）改写历史会引发那么大麻烦——所有人的本地历史都跟远端对不上了，必须手工处理。理解了这个机制，你就不会觉得“不要强推主干”是一条死板的规矩，而是一个数学上的必然要求。

3.4 动手验证：用底层命令把一次提交拆开看

光看文字印象不深，建议亲手拆一次。下面这串命令都是只读的，随便找个仓库跑一遍，不会有任何风险。

# 看当前提交对象的完整内容 git cat-file -p HEAD # 输出大致长这样： # tree 4b825dc642cb6eb9a060e54bf8d69288fbee4904 # parent 8a1f2c... # author 某开发者 <dev@example.com> 1700000000 +0800 # committer 某开发者 <dev@example.com> 1700000000 +0800 # # feat: 增加配置加载逻辑 # 顺着 tree 往下看目录结构 git cat-file -p HEAD^{tree} # 看某个具体文件对应的 blob 内容 git cat-file -p HEAD:README.md # 看暂存区里每个路径指向哪个对象 git ls-files -s # 看某个对象的类型 git cat-file -t HEAD

跑完这几条，你会对“提交是一棵树的根”这件事有非常具体的感受。HEAD^{tree}那个语法意思是“取 HEAD 指向的提交里的 tree 对象”，HEAD:README.md意思是“取 HEAD 那棵树里路径为 README.md 的 blob”。这些语法平时用得不多，但排查疑难问题时很有用，比如你想确认某个文件在某个历史版本里到底是什么内容，又不想切分支破坏当前工作区。

再补一个实用技巧：git rev-parse HEAD能拿到完整哈希，git rev-parse --short HEAD拿短哈希。写脚本或者在文档里引用某个提交时，短哈希更好读，但要注意短哈希在超大仓库里可能冲突，正式场合还是用完整的。

4. 从单人脚本到多人协作：四种工作流的适用边界

4.1 集中式工作流：主干直推的适用场景

Git 支持的第一种工作流，恰好是跟集中式工具最像的那种：所有人往同一条主干分支上提交，推送前先拉取变基。它的优点是简单到不需要培训——没有分支概念要学，没有合并策略要定，新人第一天就能上手。

适用边界比想象中窄。团队人数少（比如三五个人）、彼此改动区域不重叠、有自动化测试兜底、发布节奏快，这套模式的效率其实很高。我待过的一个小工具项目就是这样，三个人共用一个主干，每天推十几次，几乎没出过事。但只要出现两个人在同一块代码上并行改动超过半天，冲突就会频繁到让人烦躁，而且主干随时处于“可能编译不过”的状态。

用这套流程有个硬性前提：推送前必须本地跑通测试。因为主干是共享的，你推上去一个坏提交，所有人的拉取都会被污染。这就要求团队有比较强的自律，或者有个足够快的 CI 在推送后几分钟内给出反馈。没有这两样，集中式工作流很快就会退化成“谁都不敢推”的僵局。

4.2 功能分支工作流：隔离与评审的最小成本方案

这是目前最主流的做法：每做一个需求或修一个 bug，从主干切一个分支出来，做完推上去发起合并请求，评审通过后合回主干。它的核心价值是隔离——半成品不会影响别人，坏代码在合并前能被拦下来。

这套流程真正的成本不在 Git 操作，而在分支的生命周期管理。一个分支活得太久（超过一周），合并时的冲突量会指数上升，评审的人也难以理解上下文。我的经验是把分支控制在“一到三天能合回去”的粒度，如果一个需求太大，就拆成几个可以独立合入的小步骤，每步都保持主干可运行。

还有一个细节：合并方式的选择会显著影响历史可读性。三种常见做法——普通合并（保留分叉图形）、压缩合并（把分支上所有提交压成一个）、变基合并（把分支提交搬到主干末尾，保持线性）。团队内部必须统一，否则历史图会变得杂乱。我倾向于对功能分支用压缩合并，对长期分支用普通合并，理由是前者关心“做了什么功能”，后者关心“什么时候集的成”。

4.3 Git Flow 与主干开发：重与轻的两端

Git Flow 是一套分支模型，定义了主干、开发、功能、发布、热修五类分支，各自有明确的创建和合并规则。它诞生的背景是需要维护多个并行版本的桌面软件——你不能让新功能的代码混进当前版本的补丁里。这套模型的分支数量多、流转规则复杂，用在小项目上属于典型的过度设计，我见过一个四人团队硬上 Git Flow，结果每天花在分支同步上的时间比写代码还多。

主干开发（trunk-based）走的是另一个极端：所有人往主干提交，分支存活时间以小时计，未完成的功能用开关（feature flag）藏起来。它对工程能力要求最高——必须有完善的自动化测试、快速的 CI、可靠的回滚机制。但它也是持续交付场景下效率最高的模式，因为不存在“合并地狱”，集成的痛苦被摊薄到每一次提交里。

选择哪个不是技术品味问题，是团队现状问题。判断标准可以简化成三个问题：需要同时维护几个发布版本？团队规模多大？自动化测试覆盖到什么程度？三个问题的答案基本能定位到合适的模型。硬套一个“先进”的模型，往往比用个笨办法更痛苦。

4.4 四种工作流的对照与选型建议

把前面几种放在一起对比，边界会更清楚。

我个人的实践路径是：新项目先上功能分支工作流，跑顺了再根据发布节奏决定要不要往两端调整。从小团队起步的，很少需要 Git Flow；追求快速交付的，早晚会走向主干开发。最忌讳的是“照搬大厂流程”——人家的流程是为人家的问题设计的，你的问题可能完全不同。

5. 从零建库并跑通一次完整流转：可复现的实操序列

5.1 初始化与那三行必须提前做的配置

新建一个仓库，git init一条命令就够。但在这之前，有三项配置建议先做掉，能省掉后面很多莫名其妙的麻烦。

# 身份信息，提交记录里会用到，写错了要改历史很麻烦 git config --global user.name "你的名字" git config --global user.email "you@example.com" # 默认分支名，跟团队保持一致，避免每次 init 完手动改名 git config --global init.defaultBranch main # 换行符处理，跨平台协作必配 # 看你团队的习惯选，Windows 上用 true，跨平台混合用 input git config --global core.autocrlf input

第一项是刚需。我见过有人提交了几十次之后才发现作者信息是默认的机器名加内网邮箱，想改就得重写历史，团队里所有人都要重新拉取。第二项看起来无关紧要，但如果团队约定是main而你本地默认生成master，第一次推送就会多出一个分叉，徒增困惑。

第三项是跨平台协作里最容易被忽略的坑。换行符在不同系统上不一致，会导致“我只改了一行但 diff 显示整个文件都变了”这种诡异现象。配置对了之后，仓库内部统一用 LF，检出时按平台转换，问题就消失了。注意这个配置对已有文件不会自动生效，历史遗留问题需要单独处理。

初始化完成后，第一件事是写.gitignore。等提交了一堆编译产物再想清理，就得动历史了，成本高得多。常见的忽略项：依赖目录、构建输出、日志、本地配置文件、编辑器缓存目录。原则是“凡是可以由源码重新生成的，都不入库”。

5.2 三区流转的最小命令集

把一个改动从工作区送进版本库，最小路径是四步。下面这段可以直接照着敲。

# 1. 看看现在什么状态 git status git status -s # 紧凑格式，日常用这个更快 # 2. 看看具体改了什么 git diff # 工作区 vs 暂存区 git diff --cached # 暂存区 vs 最后一次提交 # 3. 挑要提交的改动放进暂存区 git add src/config.js git add -p # 交互式，按块选择，强烈推荐 # 4. 提交 git commit -m "feat: 增加配置加载逻辑，支持环境变量覆盖" # 5. 看结果 git log --oneline --graph --all -10

这套流程里，最值得养成习惯的是git add -p。它把“提交”这个动作拆成了“挑拣”和“封存”两步，逼你在提交前重新审视一遍自己的改动。我用了几年之后发现，光是这个动作就能拦下不少误提交——比如调试用的console.log、临时改的测试地址、注释掉的整段代码。

提交信息也值得单独说一句。feat:、fix:、refactor:、docs:这类前缀不是形式主义，它让git log变成可检索的。半年后你要找“哪个提交改了这个配置项的默认值”，一条git log --oneline --grep="config"就能定位。标题行控制在五十字符内，正文说清楚“为什么这么改”，而不是“改了哪些行”——后者 diff 里已经写着了。

5.3 几个高频误操作与恢复手法

概念清楚了，恢复操作其实很直观：无非是把某个区域的内容替换成另一个区域的。但实际操作里，几个命令长得太像，必须分清。

最容易出事的是第二个。git restore <file>直接丢弃工作区改动，没有确认、没有备份，敲完就没了。我自己的习惯是，在任何可能丢数据的操作前先git stash一下，哪怕只是改了两行。stash 是本地的一个临时栈，不进历史、不影响别人，用完git stash pop拿回来，成本极低，收益是心里踏实。

另一个高频问题是“提交了不该提交的文件”。如果只是刚提交还没推，git rm --cached加git commit --amend就能解决。如果文件已经进了历史深处（比如一个几十兆的二进制包），那就得用历史重写工具清理，而且所有协作者都要重新克隆。所以再次强调：.gitignore要趁早，大文件要在第一次提交前就拦下来。

5.4 我踩过的坑与长期有效的习惯

说几个纯经验的东西，文档里一般不会写。

第一个坑是在.git目录里手动操作。早期我为了“清理空间”，手动删过objects里的文件，结果仓库直接损坏，git fsck报了一堆缺失对象，最后只能重新克隆。.git目录对 Git 来说是不透明的二进制存储，除了解剖学习时只读查看，任何写操作都应该通过 Git 命令完成。

第二个坑是把版本库放在同步盘里。把工作目录放进某些自动同步工具，会在 Git 写对象的同时触发同步，导致 index 文件被并发写入、对象文件只写了一半。表现是随机出现的“仓库损坏”或“文件锁冲突”。如果确实需要多设备，正确做法是用远程仓库同步，而不是同步.git目录。

第三个习惯是提交前必看git status -s和git diff --cached。前者告诉你哪些文件在哪个状态，后者告诉你即将提交的具体内容。这两个命令加起来不到两秒，能拦掉大部分“提交了不该提交的东西”的事故。

第四个习惯是给每个分支起有意义的名字。fix/login-timeout、feat/config-loader这种命名，比dev2、test、new有信息量得多。分支名会出现在合并提交里、出现在代码评审页面上、出现在别人的git branch输出里，它是给未来的人看的，包括三个月后的你自己。

最后一个，也是我觉得最值钱的：遇到不确定的操作，先复制一份目录再动手。整个仓库复制一份的成本可能就几百兆，但能让你在搞砸之后十分钟内恢复如初。等你对 Git 的对象模型足够熟了，这个习惯自然会消失；但在那之前，它是比任何回滚命令都可靠的保险。

回到最开始那个问题：git commit那一瞬间，文件到底去了哪儿？现在你应该能给出一个像样的答案——内容被算成哈希存进对象库，路径和哈希的映射写进索引，目录结构被组织成 tree，最后生成一个 commit 指向这棵树和它的父亲，然后分支指针往前挪一格。整个过程没有“上传”，没有“覆盖”，只有对象的写入和指针的移动。把这套模型在脑子里建起来之后，你会发现 Git 的命令不再是需要背诵的咒语，而是一组可以推导的操作——想清楚要动哪个区域、要移动哪个指针，命令自然就出来了。