1. 先把Git的"存储模型"搞明白，后面的命令全通了

很多朋友学Git最痛苦的一件事是：命令背了几十遍，但一遇到实际情况还是不知道怎么处理。查了文档，看得懂每个参数，但就是不知道"什么时候该用哪个"。我带了几年技术团队，也带过不少新人，发现根子不在记性，在脑子里压根没有形成Git的正确模型。

1.1 不要把Git仓库想象成"带撤销功能的文件夹"

大多数人初学Git时，会下意识地把它理解成Word里的"版本历史"：每隔一段时间存一个快照，随时能倒回去。这个类比帮你在前两周内快速上手add、commit、push，但也是之后所有困惑的来源。

Git的存储模型更像一个小型档案室：每个文件不是"存了一份新版本"，而是每条提交记录都是一张独立的清单。这张清单上写着：作者是谁、什么时候提交的、提交说明是什么、这次改了哪些文件、每个文件改动前后的内容分别对应哪一块存储区域。而且Git不是为每个文件单独存副本，它会用内容寻址的方式，把相同内容的数据块复用起来，所以哪怕提交一万次，仓库也不会膨胀到你想象的那种程度。

我常用一个比方：Git仓库是一栋图书馆，commit不是书的再版，而是一张写着"哪本书从哪个位置挪到了哪个位置"的流水单。流水单攒得多了，你查历史时看到的不是"书的旧模样"，而是"每次搬动时发生了什么"。理解这一点，后面所有关于分支、合并、回滚的疑问都能解开。

1.2 三个区域的流转，才是Git一切操作的本质

很多教程会告诉你"Git有工作区、暂存区和版本库三个区域"，但说完就过去了，没有解释为什么要有中间那个暂存区。这里我展开讲讲。

• 工作区：你电脑上肉眼可见、随手能改的文件夹。它是草稿桌，乱一点没问题。
• 暂存区：一个临时存放"准备提交的变更清单"的盒子。它在你的.git目录里，以index文件的形式存在。你git add，就是把"这个文件当前的内容"打包一份放进盒子，并更新清单里对应的条目。
• 版本库：归档柜。git commit之后，暂存区里的这份清单会被永久记录成一条commit，归档到objects目录里。

为什么要这样设计？因为真实干活时，你经常会在同一次任务里改多个文件，但其中可能有一两个文件只是临时调试用的，你不想把它们和正式改动混在一起提交。没有暂存区的话，要么只能一次提交全部改动，要么就得用很笨拙的方式挑文件。有了暂存区，你可以像点菜一样，把想提交的菜挑进盘子，剩下的继续留着。

这一章要记住的最关键一点是：commit记录的不是你工作区的全貌，而是暂存区相对上一个commit的差异。理解了这点，你就理解了为什么改了文件之后必须add才能commit，为什么add之后又改文件，commit捕获的只是add那一刻的内容。

1.3 用一次完整提交走一遍内部流程

我建议每个初学者都做一次这个实验，它能帮你在心里建立非常牢固的模型。找一个空目录，执行git init之后，创建一个文本文件，写入一行字，然后依次执行：

git status git add . git status git commit -m "first commit"

第一次git status，你会看到文件出现在"未跟踪"区，意思是档案室完全不知道这个东西的存在。git add之后，再执行git status，文件跑到了"待提交"区，此时Git已经知道了这个文件的内容。commit之后，再执行git status，工作区干净了，意思是当前所有内容都已经被归档。

这里有个很多新手没注意过的细节：执行git add之后，如果你马上修改文件内容，再执行git status，你会看到同一个文件同时出现在"待提交"和"未暂存"两个列表里。前者是你add那一刻的内容，后者是新的改动。如果不小心直接commit，你新改的内容不会进去，commit里存的是add时的旧内容。这个"时间差"是日常开发中最容易踩的暗坑之一。

2. 日常最高频的六个操作，配合真实场景讲透

说完了模型，进入实操。我不打算按文档顺序把所有命令过一遍，那没有意义。我挑日常开发中真正高频使用的六个场景，每个场景讲清楚为什么这样做、有没有其他做法、踩过什么坑。

2.1 git clone：拿到仓库只是开始

git clone大概是所有Git用户第一个接触的命令，但很多人clone完就直接开干，忽略了两个关键信息。

第一，clone默认拉的是默认分支。GitHub上默认分支通常是main，Gitee上可能是master，如果你干活需要的是develop或者release分支，clone之后第一件事应该是git branch -a看看远程有哪些分支，再git checkout develop切过去。我见过太多新人直接在main上吭哧吭哧写了一周，最后合并不进去的痛苦场景。

第二，clone时选择HTTPS还是SSH，决定了你后面每次push需不需要输账号密码。SSH方式需要在本地生成密钥对，把公钥配置到远端平台。生成方式很简单：

ssh-keygen -t ed25519 -C "your_email@example.com"

一路回车，然后把~/.ssh/id_ed25519.pub里的内容复制到Git平台的SSH公钥设置页。这样配置一次之后，所有的clone、push、pull都不再需要输入密码。实测感受是：一旦用过SSH，就再也回不到HTTPS了，每次push输密码积累的烦躁感真的会消磨工作热情。

2.2 提交前的"自查三连"：status、diff、log

现在你已经在一个分支上，也改了文件，准备提交了。别急着add和commit，先花十秒钟做三件事。

第一件，git status，看一下当前分支在工作区、暂存区分别有哪些变动。第二件，git diff，查看未暂存的具体改动内容，逐行确认没有把调试代码、临时路径、密钥文件混进去。第三件，git log --oneline -5，看一眼最近几条commit的写法，保持你这次提交的风格一致。

这三个命令不一定每次都全用，但至少git diff强烈建议养成习惯。我见过不止一次，有人写代码时顺手把自己的绝对路径写到配置文件里，或者把带密码的测试代码提交上去，等到push完了才在日志里发现。提交前的十秒钟检查，能让你省下后面几十分钟的补救时间。

2.3 怎么才能写出"别人看得懂"的commit message

这部分在团队协作中特别重要，而且是新人和资深开发者差距最明显的地方。

一个合格的commit message应该回答两个问题：这次改了什么？为什么这么改？"fix bug"和"update code"这类消息等于什么都没说。我推荐大家用目前行业里比较通行的约定式提交风格，格式大致是：

feat(登录模块): 增加短信验证码登录方式 - 新增send_sms_code接口，用于下发验证码 - 登录接口增加sms_code参数校验逻辑 - 更新登录页前端，增加验证码输入框

第一行是标题，feat表示新功能，fix表示修bug，docs表示文档调整，refactor表示重构但行为不变。括号里写影响的功能模块，冒号后面用一句话概括。然后再用空行隔开，写几行正文，列清楚具体的改动点。

这种风格的好处是，未来你翻git log --oneline时能快速滤出自己想要的信息，比如git log --oneline --grep="^fix"列出所有修bug的提交。团队用自动化工具生成changelog时，也能直接从提交信息里抽取。老实说，开始用这种格式后，我自己的"这代码当时为什么这么写"的考古时间都缩短了一大截。

2.4 分支操作的常见误区

分支是Git的核心功能，但混淆最多的也在这里。

很多人会把分支想象成"代码的平行宇宙"，这没错，但如果只停留在这一层，就没有理解分支的本质只是一个指针——它指向某一条commit。你创建一个新分支，并没有复制任何代码，只是新建了一个可以移动的指针。新指针默认指向你当前所在的commit，所以你在这个新分支上改代码提交后，这个指针才会往前移动到新的commit。

日常开发中，我建议养成"每个功能一个分支"的习惯。新功能开一条分支，名字用feature/xxx的格式；修bug的分支用fix/xxx。这样做的好处有两点：一是主分支（main/master）永远保持可发布状态，任何时候你都可以从上面拉一个新分支去做其他事，不需要担心被别人的半成品干扰；二是做Code Review时，每个分支对应一个清晰的任务范围，审查者能很轻松地对照改动。

2.5 git log的三种实用姿势

很多人学了git log就只会看默认输出的完整列表，其实日常用得更顺的是下面几种组合。

git log --oneline --graph --decorate -20

这条命令只显示最近20条提交，每条一行，--graph会画出分支分叉和合并的线条，--decorate标出分支指针和标签的位置。分支多了以后，这个视图能帮你快速建立整个仓库最近的历史结构。

git log -p --follow -- 某个文件名

这条命令查看某个文件的完整变更历史，包括每次改动的具体代码。--follow参数能让你在文件被重命名之后依然跟踪到之前的历史，不然只能看到改名之后的部分。

git log --author="某同事" --since="2 weeks ago" --oneline

这条用于查看某个人最近两周的提交。团队周报、代码评审准备材料时特别好用。

2.6 push之前先pull，但这句老话有坑

刚接触Git的人一定会被叮嘱"push之前先pull"。这句话方向没错，但如果真的只是傻傻执行git pull，在某些团队里可能引发你完全没预料到的结果。

原因是git pull是git fetch和git merge的复合命令：先拉取远端最新提交，再和你的本地分支做合并。如果两边改动了同一个文件的同一处位置，你会被拉进一个合并冲突的流程里。对新手来说，解决冲突是很吓人的。

更稳妥的习惯是：先git fetch，看一眼远端发生了什么，再决定用git merge还是git rebase。这两个策略的区别我在下一章详细讲。这里先记住一个纪律：在push之前，确认你的本地分支包含远端分支的所有提交，否则push会被拒绝。不要用git push --force去绕过这个检查，它是灾难的源头。

3. 合并与冲突：协作中最容易翻车的环节

如果你是单兵作战，合并和冲突可能几个月遇不上一次。但在真实项目里，多人同时改同一批文件是家常便饭，这一章值得每一分钟都花在上面的时间。

3.1 merge和rebase：两种思路，两种结局

假设你从主干拉了一条分支feature，主干之后又有了新的提交。现在你想把主干的最新变更并入你的分支，有两条路：

git merge：把你的分支历史和主干历史并成一条交错的历史。最多会出现一个新的"合并提交"，它有两个父提交。好处是历史完全保留，坏处是图形看多了会乱。

git rebase：把你分支上的所有提交"摘下来"，一条一条重新接到主干的最新提交后面。效果是你的分支历史变成一条直线，看起来像主干完全没变过，你的提交只是晚了一些。好处是历史干净，坏处是提交的哈希值会变——如果别人已经基于你的旧提交做了工作，rebase会打乱他们的基础。

给个直观判断：如果是你自己的功能分支，还没有和别人共享，rebase是首选，保持提交历史线性整洁；如果是公共分支，或者不确定别人有没有基于你的提交工作过，merge是安全选择。

说实话，我早期非常痴迷rebase带来的线性历史，觉得那样很酷。后来吃了亏才明白，所谓"干净的提交历史"远不如"不破坏别人工作"重要。现在我的原则很简单：只rebase自己的分支，绝不rebase公共分支。

3.2 冲突到底是什么？三路合并的原理

冲突不是Git在"惩罚"你，而是Git在保护你。当Git发现两个分支都修改了同一处代码，它确实无法自动判断谁对谁错，这时候它能做的最合理的事情就是停下，请你来做决定。

理解这一点能大幅减少你对冲突的心理恐惧。执行git merge产生冲突时，打开那个冲突文件，你会看到类似这样的标记：

<<<<<<< HEAD 这边是你当前所在分支的内容 ======= 那边是要合入的分支的内容 >>>>>>> feature/login

<<<<<<<和=======之间的部分是当前分支的版本，=======和>>>>>>>之间是要合入分支的版本。你需要做的，是把这些标记线删除，保留或者重写出最终想要的代码，然后保存文件，再git add这个文件，继续git merge --continue。

冲突解决的本质，其实是"判断两边的代码哪一个更合理，或者如何把两边的意图整合到一起"。大多数时候不是简单的二选一，而是需要你理解两边各自在解决什么问题，再写出两者兼容的代码。

3.3 解决冲突最实用的三个排查技巧

第一，先用git status确认有哪些文件冲突了，别只看编辑器里报红的文件。有时候冲突发生在你不经意的地方，比如配置文件、lock文件，这些文件你几乎不可能手动合并出正确结果，得重新生成。

第二，用可视化工具辅助。如果你用的是VS Code，冲突文件会高亮显示，可以直接用图形界面选择"接受当前的"或"接受引入的"，或者手动编辑。我本人现在几乎不用命令行解决冲突了，太费眼神。但命令行时代练出来的敏感度还在：不管用什么工具，解决完冲突之后一定要从头到尾读一遍最终代码，很多人在可视化界面里点了"接受引入的"，但实际上引入的版本只是某一个人的半成品，组合起来逻辑根本不通。

第三，合并不代表完成。无论多自信冲突解决得没问题，合并之后务必跑一遍测试。这听起来是废话，但真的有很多冲突是因为两边各自改了同一个函数的调用约定，合并后能编译、能跑，但运行到某条路径就崩了。

3.4 rebase冲突和merge冲突有一个关键区别

如果你用的是rebase，冲突的解决流程和merge大致相同，但有一个细节会坑到很多人：rebase时的冲突提示不会出现"merge commit"让你一次性解决。rebase是一条一条提交重新放，所以可能在第一处就停下，你解决完之后，继续rebase，又可能在第二处停下，又得解决一次。

这个过程不是bug，而是rebase的内在逻辑：每个提交都对应一次独立的"重放"，你要保证每个提交放上去之后都是完整的。第一次rebase遇到冲突时，我差点以为Git卡住了，怎么resolve了还重复出现同样的冲突，后来才理解这完全是设计如此。

给新手的建议是：如果你的分支上有大量提交，而且和主干差异很大，rebase可能让你陷入漫长的重复冲突解决中。这种场景下直接用merge往往效率更高。不要为了追求线性历史而付出不成比例的时间成本，历史是给人看的，代码能用才最重要。

4. 写错代码、搞丢提交、提交了不该提交的文件：实战救援手册

再熟练的老手也免不了有手滑的时候。这一章直接讲事故处理，每一个都是我在真实项目或带新人时遇到的场景，背后是真实的救援经验。

4.1 刚commit完就发现代码写错了，怎么办

场景很常见：你高高兴兴提交了一个commit，然后突然发现里面有个低级错误。下一个动作千万别是"再改一下又提交一个"，而是根据错误性质选择处理方式。

如果只是想修正这个commit的内容，用git commit --amend。它会把你暂存区里的变动合入上一条commit，而不是生成一条新的。提交后，用git log --oneline看，会发现commit数量没有增加，只是上一条的内容变了。

但注意：amend是会改变提交哈希值的。如果这个commit已经push到远端，并且别人可能已经拉取过，amend之后你再push会被拒绝，被迫使用--force，这又会把别人本地基于旧提交的工作根基抽掉。所以amend只适合处理尚未push的本地commit。这个边界我用一句话给团队定过规矩："本地没推过的随便改，推过shared分支的绝不用amend。"

4.2 reset和revert：一字之差，一个改写历史，一个不改写

这是Git中非常容易混淆的一对命令，我没见过谁第一次学就能完全厘清。

git reset是把当前分支指针往回移动，比如你连续提交了三次，git reset --hard HEAD~3会把分支直接移回三次之前，那三个commit在分支上就消失了。消失不等于销毁，它们还在对象库里，但你的正常操作已经看不到它们。

git revert则完全不同，它不是移动指针，而是生成一条新的反向提交，把指定commit的改动全部撤销，然后指针照常前进。历史看起来多了一条"撤销了某次改动"的记录，之前所有提交都原样保留。

落实到使用场景：

--soft、--mixed、--hard的区别其实就是一个问题：指针回退之后，那些改动去哪？--soft把改动留在暂存区，--mixed（默认）把改动留到工作区，--hard直接丢弃。日常用最多的组合是：只想撤销commit但保留代码改动时用--soft；想把改动打回工作区重新整理时用--mixed。

4.3 reflog：误操作后唯一的"后悔药"

如果你已经用了git reset --hard把改动丢了，或者不小心删了分支，还有没有救？有，前提是你记得那串提交的哈希值，或者能通过git reflog找到。

git reflog记录的是你这个本地仓库里所有HEAD指针移动的历史，包括reset、rebase、checkout等操作。比如你git reset --hard干掉了三个commit，执行git reflog，会看到之前HEAD指向过的那串哈希值。找到对应的哈希，再git reset --hard 那个哈希，就能把分支指针找回来。

这里要强调的是，reflog是本地的，不会跟着push同步到远端。所以如果你在一台机器上误删了提交，而另一台机器克隆过同一个仓库，理论上也可以去另一台机器上找到对应的commit再拉回来。但最稳妥的做法还是：重要操作前留个心眼，或者干脆在push之后不随便用--hard。

4.4 把大文件或密钥文件提交进Git了，怎么清理

这是真实工作中比较麻烦的事故之一。你写代码时为了测试，把一个几十MB的二进制文件或者包含密码的.env文件add并commit了，然后push上去。通常等你想起来的时候，可能已经又提交了好几次。用git reset或者删除文件再提交，都仅仅是让这个文件之后不再出现，已经提交进历史记录的那一坨，依然躺在仓库里，只要有人clone就能翻出来。

正确的处理分两步。

第一步，从当前状态移除这个文件的跟踪：git rm --cached 文件名，这个命令的意思是"从Git跟踪中移除，但保留工作区文件"。这样你的本地文件还在，但Git不再跟踪它。

第二步，如果你已经在push之后想起这事，需要重写历史，把该文件从所有历史提交中抹掉。最常用的工具是git filter-branch或者BFG Repo-Cleaner。我倾向于用BFG，因为它的操作指令简单到夸张：

java -jar bfg.jar --delete-files "文件名" 你的仓库路径 git reflog expire --expire=now --all && git gc --prune=now --aggressive

但要说清楚，重写历史意味着所有后续commit的哈希都会变，所有克隆过这个仓库的同事都会受影响，必须提前通知协调，甚至可能需要重新clone而不是pull。如果这个敏感文件已经push到了公开的远端，唯一的建议是：立即去远端平台把仓库设为私有或锁定，并和知情者沟通。你不可能保证它已经不在任何人的电脑上了。

5. 让Git真正成为日常效率工具的六个习惯

最后一个部分的角度不太一样。当命令都熟练了以后，真正能让Git发挥价值的，其实是几个很容易被忽视的习惯。它们不会直接出现在任何一份命令速查表里，但我实测下来价值很大。

5.1 提交信息的"原子化"原则

我见过很多人为了省事，会把一个功能、三个bug修复、一次重构混在一个commit里提交。结果就是，半个月后有人发现某个改动影响了线上行为，想查清楚是哪一次提交引起的，git bisect面对这种"大杂烩提交"基本无能为力。

更好的做法是：一个逻辑改动一个commit。比如你改了一个功能，顺手修了个拼写错误，那就分成两条commit。这不是形式主义，而是让代码历史具备"可回溯性"。未来排查问题时，你能把问题精确锁定在某个commit上，而那一个commit的改动量足够小，小到你能轻松审计它的全部内容。

5.2 .gitignore要在项目一开始就配好

很多新人会忽略.gitignore，直到把node_modules、target、__pycache__这类目录提交进Git，把仓库撑得很大之后才意识到问题。而这时候清理历史又是一场折腾。

我的习惯是：项目初始化时就把.gitignore写好，不同语言的模板可以直接从GitHub的gitignore仓库里复制。然后提交之前跑一下git status，确认没有不该跟踪的东西混进来。这里有个隐藏很深的坑要提一下：.gitignore只对尚未被跟踪的文件生效。如果某个文件已经被add并commit了，之后你再把它写进.gitignore，Git依然会继续跟踪它。这时候需要执行git rm --cached取消跟踪，这个细节我在上一章事故处理里已经讲过，但它值得在习惯层面再强调一次，因为几乎每个人都会在这里踩一次。

5.3 用alias把高频命令压缩成肌肉记忆

长命令的输入成本其实比想象的高，尤其是带参数的那几个。我建议把最常用的一组命令配成别名，修改~/.gitconfig里对应的地方。

git config --global alias.st status git config --global alias.co checkout git config --global alias.br branch git config --global alias.cm "commit -m" git config --global alias.lg "log --oneline --graph --decorate"

配置完成之后，git st就是git status，git lg就能看到清爽的提交图。别小看这几个别名的节省，频繁切换分支、查看状态时，少敲几个字符，整体的专注度差异是很明显的。配置是本地生效的，不影响团队，纯粹是自己用着舒服。

5.4 给常用分支加上"保护"概念

不管你用的是GitHub、GitLab还是Gitee，都建议在远端平台的管理设置里，把主线分支（main/master）启用保护规则。启用后，分支不能被直接push，所有合入主干的操作都必须通过Pull Request或Merge Request。

这一步的意义不只是流程上的仪式感，而是在机制层面防止"手滑"。很多代价高昂的事故都起源于某个人直接在主干上提交了一个未经验证的版本。保护分支之后，每次合入都有一次环节让同事看到改动，这条保护值得你用两分钟去配置，换来以后每月的安心。

5.5 善用git stash处理"还没做完就要切换分支"的尴尬

场景很常见：你正在feature/A上改代码，改到一半，测试同学告诉你线上有个紧急bug得马上修，得切到hotfix分支。如果直接git checkout，Git会因为工作区有未提交的改动而拒绝切换。

有两个选择。一个是硬着头皮先提交，再切过去，但你会往分支历史里塞一条半成品commit；另一个是git stash，把当前改动先收起来，工作区恢复干净，切走，修复完线上bug之后切回来，再git stash pop恢复之前改动。更讲究一点，stash时可以用git stash save "描述信息"，这样多个stash之间你能分辨谁是谁。注意stash是本地保存的，不跟着远端走，所以如果机器坏了，stash里的工作也没了，重要工作别只会stash，该提交的还是要提交。

5.6 IDE与命令行，并不是二选一

我知道有些老开发者对IDE里的Git可视化界面嗤之以鼻，但我个人认为，工具没有高下之分，熟手用什么顺手就都是好工具。IDEA和VS Code集成的Git功能已经很强了，图形化diff、图形化解决冲突、图形化分支管理，对效率的提升是实实在在的。

我自己现在的工作流是混合的：常规提交会用命令行加别名快速完成，但解决复杂冲突、查看历史图时一定打开IDE的可视化界面。关键不在于哪个更"正统"，而在于哪个能让你把大脑用来思考代码逻辑，而不是浪费在记命令参数上。尝试找到你自己的混合节奏。

最后分享一个我用了很久的小习惯：每次要push之前，跑一次git log --oneline main..当前分支名，看看当前分支相比主干多了哪些commit。这个动作两秒钟就能完成，却总能提醒我是不是有些调试用的临时提交混进来了。Git是个很宽容的工具，绝大多数错误都有挽回办法，但这不代表我们应该故意制造挽回路。把它当做一个固定的日常动作，远比你练熟一百条救援命令更有用。