1. 三个区与对象模型所有git命令的底层逻辑刚上手git的时候我犯过一个很典型的错误以为git就是一个简单的保存历史版本工具于是满脑子只记add、commit、push三个词。结果一到团队协作同事问我你刚那个hotfix分支推了吗你rebase一下再提PR我整个人都是懵的。后来花了不少时间才明白git之所以有那么多命令是因为它内部有一套非常清晰的对象模型所有命令本质上都是在操作这套模型。git的核心不是记录文件的副本而是一个内容寻址的文件系统。它把文件内容、目录结构、提交信息、分支指向全部抽象成对象这些对象通过SHA-1哈希值唯一标识。理解了这个前提你会发现git命令其实没有那么多魔法每个命令背后都对应着对对象图的一次操作。常说的三个区——工作区Working Directory、暂存区Index/Staging Area、版本库Repository——对应的就是git内部对象的不同状态。工作区是你正在编辑的普通文件夹暂存区是下一次commit的候选名单版本库里则存放着真正不可变的commit对象。git add做的事情是把工作区文件的快照写入对象库并更新暂存区的索引git commit做的事情是把当前暂存区的索引固化成一个新的commit对象。有个很形象的类比工作区是你桌面上的草稿纸暂存区是你要放进文件袋的页面而版本库是上锁的文件柜。你可以在草稿纸上随便涂改只有放进文件袋的页面才会被盖章归档归档之后的内容就不能再改了——commit对象一旦创建就完全不可变这就是git保证历史可追溯的基础。# 查看三个区的状态这是最高频的命令 git status # 工作区 - 暂存区 git add file # 暂存区 - 版本库 git commit -m commit message提示git commit --amend之所以能修改上一次提交本质上是创建了一个全新的commit对象来替换旧的commit旧的commit仍然留在对象库里只是不再被任何分支引用。HEAD指针指向当前所在的分支引用而分支引用指向某个commit对象。每次commit不是覆盖上一个commit而是在commit对象图中追加一个子节点并移动当前分支的引用。所以git的历史是一棵有向无环图DAG不是一条直线。这个认知对后面理解merge、rebase、reset都至关重要。2. 日常提交的完整链路从add到commit的细节与规范2.1 别再用git add .了试试路径和交互式添加很多新手习惯性git add .把所有改动一次性塞进暂存区。这种方式在个人项目里没大问题但一旦进入多人协作或者你的改动跨越了多个逻辑模块这种方式会给code review带来很大麻烦。评审人需要从一堆杂糅的改动里分辨出哪些属于功能A、哪些属于修复B体验极差。更推荐的做法是按逻辑拆分提交。比如我改了一个接口又顺手修了一个样式bug我会分两次提交# 只添加某个文件 git add src/api/user.js # 只添加某个目录下的所有改动 git add docs/ # 交互式添加按hunk改动块逐个选择 git add -pgit add -p是我比较常用的命令它会将文件的每个改动块单独列出询问你是stage、skip还是split。这样同一个文件里如果包含两个不同目的的改动就能分别提交到不同的commit里。对于追求提交粒度干净的团队这个命令几乎是必备技能。2.2 commit message规范让历史可读提交信息是写给未来的自己和其他协作同事看的不是形式主义。我见过太多仓库的commit message写成update、fix、修改一个月后回头看完全不知道当时改了什么东西。推荐的格式是type(scope): subject这也是社区里比较常用的约定类型含义典型例子feat新功能feat(login): 增加手机号登录方式fix修复bugfix(cart): 修复库存不足时仍可下单的问题docs文档变更docs(readme): 补充部署说明refactor重构不改功能refactor(api): 提取公共请求拦截器style代码格式调整style(button): 调整组件缩进perf性能优化perf(list): 使用虚拟滚动优化渲染写完提交信息后用git log --oneline看历史一眼就能明白项目的演进脉络。如果发现提交信息写错了commit还没有push到远程可以用git commit --amend修改最近一次提交的信息。2.3 合并多个提交commit --amend与交互式rebasegit commit --amend除了修改message还常用于想在上一次提交里加一个漏掉的文件。操作方式# 漏掉了一个配置文件不想新增一个commit git add config.yml git commit --amend --no-edit--no-edit表示沿用原来的提交信息不加这个参数会进入编辑器让你重新编辑message。需要注意amend一定要在push之前用一旦push到远程再amend就会导致本地和远程的历史分叉需要force push才能同步这对团队协作来说是件麻烦事。如果你想合并的不只是最近一次而是最近三次提交就要用到交互式rebasegit rebase -i HEAD~3编辑器会列出最近三次提交你可以把pick改成squash将当前提交合并进上一个提交调整提交顺序删除某个提交直接删除对应行修改某个提交的message把pick改成reword你还可以把一个功能分支上十几个零碎的提交整理成两三个语义清晰的提交再合回主分支。这样主分支的历史会非常干净。但是注意rebase也是在push之前做才有意义push之后rebase会导致远程和本地分叉。3. 分支操作与HEAD游离团队协作的第一次冲击3.1 分支的本质是可移动的指针git branch系列命令核心就是在commit对象图上创建、移动、删除指针。创建分支的成本极低因为它只是新建一个指针指向当前commit不做任何文件拷贝。这也意味着git的分支特别轻量可以随便开。# 创建并切换到新分支 git switch -c feature/payment # 查看本地分支 git branch # 查看所有分支含远程分支 git branch -a # 删除本地分支-D强制删除 git branch -d feature/payment注意git switch是git 2.23引入的命令比git checkout语义更清晰。checkout既负责切换分支又负责恢复文件职责混乱新手容易搞混。现在的项目我基本只用git switch来切换分支。3.2 HEAD游离状态为什么切到历史commit后你的新提交不见了这是很多人会遇到的惊吓场景执行git checkout 某个commit的hash然后改了代码、提交了接着想切回自己的分支发现刚才的提交不见了。原因在于HEAD此时没有指向任何分支而是直接指向了一个具体的commit。你在这个状态下提交新建的commit没有任何分支引用它切走之后它就成了悬空对象。# 看到 detached HEAD 提示说明你处于游离状态 git checkout commit-hash # 此时如果做了提交需要这样挽救基于当前HEAD创建一个新分支 git switch -c rescue-branch如果你的本意是临时看看历史版本的代码不如直接基于它改一版那正确做法是开头就先创建分支git switch -c archive/legacy-ui commit-hash这样HEAD始终指向archive/legacy-ui分支提交不会丢失。游离状态本身不是错误但最好只在查看历史文件时使用不要在游离状态下进行代码修改。3.3 merge和rebase同样是合并差别在哪里合并两个分支的改动git提供了git merge和git rebase两种手段这是git里最让人纠结的选择。merge的机制是创建一个新的合并提交merge commit它的父节点有两个分别指向两个分支的最新提交。历史会如实记录这里发生过一次分叉合并优点是不改变任何已有commit安全可追溯缺点是历史图上会多出很多杂乱的合并点。rebase的机制是把当前分支的commit搬移到目标分支的最新提交之后逐个重放。重放不是复制原commit而是基于新的父节点重新生成commit所以commit的hash会改变。rebase之后的历史是一条干净的直线但代价是重写了历史如果分支已经push到远程这种重写会带来协作问题。我的使用原则很简单个人分支、还在本地、没人基于它开发 → 用rebase保持历史干净共享分支、多人协作用的分支 → 用merge或者干脆不直接rebase有一次同事把一个已经push到远程的feature分支rebase了主分支然后force push结果另一位基于旧feature分支开发的同事在pull时冲突到崩溃。那次之后我在团队里定了一条规矩rebase只允许在本地进行凡是push过的分支一律merge。4. 回滚与修正reset、revert、stash的取舍逻辑4.1 reset的三种模式soft、mixed、hard分别动了什么git reset是git里最容易造成数据丢失的命令之一理解它的三种模式才能真正理解它在做什么。reset做的事情是移动当前分支的指针并对三个区产生不同程度的影响模式移动HEAD指针更新暂存区更新工作区典型用途--soft是否否撤销commit但保留改动在暂存区--mixed默认是是否撤销commit且取消暂存改动回到工作区--hard是是是彻底丢弃commit及所有改动# 撤销最近一次提交但保留改动在暂存区重新提交时方便改message git reset --soft HEAD~1 # 撤销最近三次提交改动全部回到工作区重新组织提交 git reset HEAD~3 # 彻底回滚到某个commit丢弃之后所有改动危险 git reset --hard commit-hash--hard一旦执行工作区、暂存区都会被覆盖如果那些改动没有别的备份比如其他分支、stash基本就找不回来了。所以建议在用--hard前先把当前改动stash起来或者开个备份分支。4.2 revert不重写历史的安全回滚reset会改写历史这在远程共享分支上是不可接受的。如果你要撤销一个已经push到远程的提交应该用git revert。revert的本质不是把指针挪回去而是生成一个新的提交这个提交的内容是反向应用目标提交的改动。比如某人提交了一个删除了某函数的功能revert那个提交会把这个函数加回来同时保留所有人后来的改动。# 撤销最近一次提交并新生成一个revert提交 git revert HEAD # 撤销指定的提交 git revert commit-hashrevert不改变任何已有commit因此永远不会产生历史分叉是协作中撤销代码的标准方案。如果有多个需要撤销的提交可以按从新到旧的顺序依次revert。4.3 stash临时藏起改动开发到一半突然需要切分支处理个紧急问题又不想提交半成品——这是git stash最典型的场景。# 把当前所有改动存入stash工作区恢复到干净状态 git stash push -m wip: 购物车优惠计算 # 查看stash列表 git stash list # 恢复最近一次stash并删除记录 git stash pop # 恢复指定stash但不删除记录 git stash apply stash{1} # 查看stash里具体改了哪些内容 git stash show -p stash{0}需要注意stash默认不包含未跟踪的新文件untracked files如果你新建了一个文件且还没addgit stash不会保存它。想一并存入需要加上-u参数即--include-untracked:git stash push -u -m 包含未跟踪文件的改动另外不要长期保留在同一个stash里反复切换过了一段时间你基本会忘记stash里存的什么。建议stash的存活时间不超过当天紧急问题处理完就立刻pop回来。5. 远程协作push、pull、fetch与冲突的正面处理5.1 fetch与pull的本质区别别忽略那个隐式mergegit pull是git fetchgit merge的组合命令。fetech只做一件事把远程仓库的最新提交和分支信息拉取到本地的远程追踪分支如origin/main不会动你本地的工作区和当前分支。pull则会在fetch之后自动将远程的更改合并到当前分支。理解了这一点你就知道为什么有时候同事说我pull了但是什么都没变——因为pull可能因为没有可合并内容而没有任何变化。我更推荐显式执行fetch再决定merge还是rebase# 拉取远程所有分支和提交信息 git fetch origin # 查看本地与远程的差异 git log --oneline HEAD..origin/main # 确认差异无误后再进行合并 git merge origin/main这样做的额外好处是可以在合并前先检查远程的改动是否与自己的改动冲突并且如果远程有多个提交你还可以把fetch出来的内容先用一个临时分支做验证确认没影响再真正合并到自己的主干。5.2 冲突的本质与解决流程读分隔符而不是瞎删冲突不是git搞坏了你的文件而是git在自动合并时发现两边的改动在同一位置且无法判断应该保留哪一边。此时git会在冲突文件中插入标记 HEAD 当前分支的改动 另一侧分支或远程的改动 feature/login解决冲突的正确姿势打开冲突文件阅读到之间的内容根据业务逻辑决定保留哪一段、删除哪一段或手动混合两段删除所有的冲突标记行git add file标记为已解决如果是merge执行git commit如果是rebase执行git rebase --continue注意不要图省事直接git checkout --theirs或--ours整个文件。冲突往往只有一小段整文件覆盖容易把对方无关的改动也丢掉。逐个hunk解决细心一点。5.3 远程推送失败的常见原因与应对git push报错大概是新人在协作中遇到最多的场景。常见原因有三种远程有本地没有的提交需要先pull或fetchmerge/rebase解决完冲突再push非快进推送被拒绝如果你push的分支历史与远程不一致git会拒绝推送避免覆盖别人的提交。你本地如果和远程分叉了需要把远程的改动合并回本地然后再push权限不足确认你是否被添加为仓库的协作者或者是否有相应的写权限# 查看push会被拒绝的原因 git remote -v # 查看本地领先/落后远程几个提交 git status -sb # 推送并设置上游分支 git push -u origin feature/payment-u参数第一次推送时用建立本地分支与远程分支的追踪关系之后直接git push就能推送到对应的远程分支。6. 查看历史的多种姿势log的筛选、图形化与diff定位6.1 常用log参数让提交历史图更直观git log是最基础的但参数非常丰富。我常用的组合是# 单行简洁输出 git log --oneline # 带图形化的分支结构 git log --graph --oneline --all # 查看某个文件的所有提交历史 git log --oneline -- src/utils/date.js # 按作者过滤 git log --author某开发者 # 按时间范围过滤 git log --since2024-01-01 --until2024-03-01 # 搜索提交信息 git log --grepbugfix--graph配合--all能从全局视角看到所有分支的关系图这比在网页端看草稿要直观得多。我在review大型分支时经常用它来梳理合并结构确认每个提交的来源。6.2 diff的进阶用法不要看到一堆改动就头大git diff用于查看改动内容。基础用法是# 查看工作区与暂存区的差异 git diff # 查看暂存区与最近一次提交的差异 git diff --staged # 查看两个commit之间的差异 git diff commit-A commit-B # 只看某个文件的差异 git diff -- src/App.js有经验的开发者还有一个技巧git diff加上--stat参数可以只显示每个文件的增删行数快速了解改动的分布范围不必钻进具体内容里。git diff HEAD~1 HEAD --stat6.3 show与blame定位某行代码是什么时候被谁改的排查问题时经常需要确认这一行是哪个提交引入的。git log -p file可以查看文件每次commit的具体改动但更直接的定位工具是git blame# 查看文件每一行最后一次被修改的commit、作者、时间 git blame src/components/Button.jsxblame输出里第一列是提交hash第二列是作者加时间之后是行号和代码内容。看到某一行有问题可以用hashgit show hash查看那个提交的完整上下文了解当时为什么要这样改。另外git show还可以直接查看某个提交的具体内容和改动统计git show commit-hash --stat7. 事故救援手册从误删分支到丢失commit的保命手段7.1 refloggit最被低估的救命命令如果你误用了git reset --hard或者误删了分支变化发生的一瞬间会觉得自己完了。但git其实有两年内的所有HEAD历史移动记录存在.git/logs/下的reflog里。git reflog能列出你执行过的每一次HEAD移动、切换、reset等操作git reflog输出里每一行都记录了HEAD在某时刻指向了哪个commit。假设你误操作reset --hard回到了一个旧commit原来的新commit的hash在reflog里仍然清晰可见# 从reflog里找到丢失前的commit hash然后 git reset --hard 那个hashreflog的保留期限通常是90天默认30天可通过gc.pruneExpire或gc.reflogExpire调整这意味着误操作后的恢复窗口其实很长。7.2 误删分支的恢复用reflog和分支重建删除分支只是删除了指针commit对象不会立刻消失它们仍然在对象库里直到被gc清理。恢复思路# 假设你误删了 feature/login 分支 git branch -D feature/login # 查看reflog找到feature/login最后一次指向的commit git reflog # 用那个commit重建分支 git branch feature/login commit-hash有一个细节如果你删分支之前还操作了很多次checkout、switchreflog里的记录会被其他操作顶掉找起来稍微麻烦点。所以误删分支后最好马上停下来不要东点点西点点直接用git reflog | grep feature/login找到最后一条相关记录。7.3 彻底丢失工作区改动的最后一根稻草git stash的栈记录也存在reflog类似的机制里。如果你git stash pop之后发生了冲突pop失败了改动不会立刻消失你可以去stash里再拉回来# pop冲突后改动还在stash里重新应用 git stash apply stash{0} # 如果应用后冲突解决了但想要保留原来的stash不用drop还有一个冷门但有效的技巧所有commit对象都会保存在对象库里直到gc真正运行。如果某个提交的hash你知道哪怕是别人发你的你可以通过git cat-file -t hash # 查看对象类型 git checkout hash # 意外恢复8. 效率技巧别名、子模块与常用的工作流建议8.1 配置常用alias把高频命令缩短git允许在全局配置里设置命令别名git config --global alias.co checkout git config --global alias.br branch git config --global alias.ci commit git config --global alias.st status git config --global alias.lg log --oneline --graph --all配置完之后可以直接git co、git br、git st、git lg。我自己还配了git config --global alias.unstage reset HEAD -- git config --global alias.last log -1 HEAD --statgit unstage会增加一个稍微直观的取消暂存命令对刚入门的人来说比git reset HEAD --更友好。8.2 子模块的正确打开方式什么时候该用什么时候别用git submodule用于在一个仓库里嵌套另一个仓库常见的使用场景是多个项目共享一个公共组件库或者项目依赖某个固定版本的SDK的源码。# 添加子模块 git submodule add url path/to/module # 克隆包含子模块的仓库需要递归拉取 git clone --recurse-submodules url # 更新子模块到最新提交 git submodule update --remote但子模块的traps非常明显子模块的提交状态在父仓库里只是一个commit指针如果子模块改了代码但不更新父仓库的指针其他人clone下来看到的子模块代码就不会同步。团队协作中子模块经常引发我这明明是更新的代码你那边怎么是老版本这类问题。我的建议是能用包管理器npm、cargo、Go mod等管理依赖就不用submodule。只有在你需要把整个源码引入项目里做深度定制、且定制内容需要和主仓库分开版本控制时submodule才值得用。8.3 个人项目的分支工作流建议结合我自己的实践最后给出一套简单实用的分支策略参考main永远保持可发布状态只允许合入经过review的代码feature/*每个功能一个分支从main切出开发完合回mainfix/*临时修复分支快速解决线上问题提交频率功能开发中按逻辑拆分多次提交不要憋着一个巨大commit塞进去合入方式规模小的改动用rebase合保持线性规模大、多人参与的用merge合这套流程简单直接没有多余的复杂度对三五个人的团队、甚至个人项目都适用。等团队规模上去了再考虑更严格的分层策略也不迟。最后聊一个我踩过多次的坑不要长时间不pull、然后在本地闷头改。我在某个项目里曾经连续两周没有fetch过主分支结果合并时积压了上百个冲突光是清理就花了整整一天。现代git工作流里频繁同步、小块提交、及时解决冲突是减少痛苦的核心原则。与其把精力花在背命令上不如把这些高频命令练成肌肉记忆真正遇到复杂问题时你已经拥有了理解它们底层逻辑的能力。