Git 用到现在我越来越确信一件事分支才是 Git 的灵魂。要说 add、commit 这些操作SVN 时代的人学起来也快但一讲到分支很多老手反而会露出困惑的表情。因为大家下意识里还是把“分支”理解成把代码复制一份另起炉灶于是切分支慢、合并冲突多、push 被拒这些事就全成了玄学。这篇是 Git 系列里的第五篇我打算从 commit 和 HEAD 的底层关系讲起把分支的创建、切换、合并、远程协作一次讲透最后再把我这些年踩过的高频分支坑位挨个晒出来。读完你会明白所谓的“平行宇宙”并不是比喻——它就是你每天都在使用的分叉历史。1. 分支的底层真相commit、HEAD 与那个会移动的指针1.1 commit 其实是一张快照加家谱很多教程爱说 Git 存的是快照但大部分人背完这个结论实际操作时还是会下意识用差异去理解于是很多奇怪行为就解释不通了。我建议你直接去看一个 commit 对象到底长什么样在仓库里执行git cat-file -p HEAD会看到tree、parent、author、committer和message这几栏。其中tree指向的是本次提交时整个工作目录的文件快照树parent指向前一个 commit合并提交会有多个 parent作者和提交者信息记录了是谁在什么时候写的message 就是我们填的提交说明。你可以把每个 commit 想象成一张入职登记表我当时的完整状态是这个我的上一任是那位。因为每个节点都带着祖先指针提交历史才得以串成一条可以回溯的链条。理解这一点是理解分支的第一步既然 commit 是这样一个完整实体那么“分支”就不需要复制任何文件它只需要知道哪个 commit 是这条线的头。1.2 分支不是文件夹而是一块会移动的铭牌默认分支叫 master 还是 main其实不那么重要重要的是它本质不过是一个引用reference存在于.git/refs/heads/目录下。你可以用文本编辑器打开那个文件看看内容就一行一个 40 位或 64 位的 SHA-1/SHA-256 哈希。所以当你执行git branch dev时Git 真正做的事情只是在.git/refs/heads/里新建一个文件把当前 HEAD 指向的 commit 哈希写进去。没有复制文件没有新建目录没有重新计算任何东西唯一开销就是几十字节的文本。这也就是为什么 Git 创建分支近乎零成本——它只是在一本名片册上多写了一个名字。切换分支时事情会更丰富一些。git switch dev会做三件事把 HEAD 这个符号引用从 master 切到 dev把 dev 指向的 commit 当作目标快照同步索引和工作区把文件“换”出来。如果 dev 和 master 指向同一个 commit切换几乎是瞬间完成的如果两者差得很远Git 也会尽量只做增量更新能不改的文件绝不动。顺带提一嘴git checkout和git switch的关系两者底层干的是同一件事但switch是后来拆出来的职责更纯的命令checkout还兼任恢复单个文件等能力。新项目里我更推荐养成switch的习惯命令意图清晰不容易把分支切换和文件恢复混在一起。1.3 分离 HEAD你正游荡在平行宇宙之外当我说“分支是指针”时你可能还有点半信半疑。那就做一次git switch --detach HEAD~3此时 HEAD 不再指向任何分支名而是直接指向一串哈希。这个状态下你依然可以写代码、可以 commit但你每提交一次没有任何分支跟着前进这些新提交就变成孤悬在空中的“悬空提交”。这种状态最经典的翻车现场是开发者发现代码丢了其实只是自己在分离 HEAD 时提交了几次又切回到原来的分支悬空提交暂时失去了引用入口被 GC 的回收机制慢慢清理掉。处理办法很简单只要在分离状态下执行git switch -c fix/xxx就能把当前位置转成一个带名字的分支。多实验几次detach → 提交 → 找回你对分支的理解会比读十篇教程都扎实。2. 分支模型不是玄学master、dev、feature、hotfix 该怎么排兵布阵2.1 Git Flow经典但不一定适合你刚接触分支管理的人大都会被 Git Flow 那套复杂的模型震撼到master、develop、feature/*、release/*、hotfix/*各司其职看起来特别规整。Git Flow 的价值在于它把一个项目的生命周期分得很清楚master永远对应已发布的版本develop是集成分支功能在feature分支上开发后合回develop发版前拉出release分支做 Regression 测试线上出问题则从master拉hotfix。但我要先泼一盆冷水如果你是一个快速迭代、每天可能发布多次的团队Git Flow 反而会让你疲于奔命。多一条release分支就等于多一道流程关卡多一套分支约定就等于多一份协作成本。Git Flow 更适合那些有严格发版周期、需要维护多个大版本的产品团队——桌面软件、嵌入式、老牌企业应用等等。做 SaaS、做 Web 持续交付的团队根本不值得背这一整套重量级流程。2.2 轻量主线模型让 main 一直保持可部署这些年我更倾向于在团队里推行一种简化模型只有一条长期分支main它随时可以部署所有新功能都基于main拉短期分支开发完合并回来然后删除分支。main上的每次提交都必须保持可运行状态谁弄红了主干谁负责第一时间修复。这个模型下通常不再设dev长分支因为每次合入main就是一次小步发布。有人会问那我现在的工作流是 master dev feature是不是必须改成轻量模型不是必须改。关键要看你的分支模型能否回答一个问题“线上出了 hotfix我需要同时在几个地方修改”如果答案是永远只有一个地方主线模型就够用如果答案是我要同时维护 1.0 和 2.0 两个线上版本那 Git Flow 或类似多主线模型才真正有意义。分支模型是写给团队看的协作契约不是用来炫技的流程图。2.3 我在 master 上写了代码怎么搬到 dev 上热词里有条很典型的求助我在 master 上写的代码怎样剪切到 dev 上可见这是个高频困惑。处理方式取决于你的改动处在什么状态。如果你只是改了工作区文件还没 commit那最简单git switch -c dev——新建并切换到 dev 分支未提交的改动会跟着你一起过去然后你git add git commit提交就直接落在 dev 上。注意这里最好用switch -c新建分支而不是直接切到已有 dev因为如果本来就存在 dev切过去后可能把改动带到一个你不想待的地方。如果你已经在 master 上 commit 过了也有两种思路一个是把改动截取到 dev用git switch dev然后git cherry-pick 那串哈希再把 master 上的原提交处理掉比如 reset 回原位另一个如果你其实只是想从当前位置新建一条 dev 线可以git switch -c dev让 dev 从当前 commit 开始长然后git branch -f master 原先的哈希把 master 掰回原来的位置。总之记住切分支只改变引用指向文件是否跟着走取决于增量状态这个原理操作时心里就有底。2.4 分支命名约定团队配合的关键分支名的价值不在于好看而在于一眼能看出这条分支要解决什么问题、可以相信到什么程度。我一般建议团队统一前缀feature/*表示新功能fix/*或bugfix/*表示修复hotfix/*表示线上紧急修复refactor/*表示重构docs/*表示文档release/*表示发版准备。分支名里最好带上关联的工单号或需求号比如feature/PAY-1234-alipay-refund。这样将来无论是 human 还是工具自动化看到分支名就能推断上下文。定这个规则容易难的是坚持。我的经验是规则最好由团队一起投票敲定写进仓库根目录的CONTRIBUTING.md而不是某个人口头说一嘴。因为这个约定一旦乱掉代码审阅、流水线配置、自动删除过期分支的脚本全都会跟着遭殃。3. 合并的代价与选择merge、rebase、cherry-pick 到底怎么选3.1 一次 merge 背后是三路合并不少人的 Git 知识停留在merge 就是把两边代码合起来遇到冲突就不知所措。其实 merge 的内部逻辑是三路合并three-way merge以两个分支的最近共同祖先为基准点分别比较当前分支和目标分支相对这个基准的差异然后把两边差异都应用上去。举个例子feature 从 main 的 A 点分叉feature 上改了文件 F 的第一行main 上同时改了 F 的第三行由于这两处改动互不重叠Git 能自动合并如果两边恰好都改了第一行Git 就报冲突把两种版本都留在文件里等你人工决定。这就是为什么合并结果并非简单地取新文件也不是逐行 diff 两个版本而是基于三方对比。理解了这个机制你就明白为什么有些冲突看着莫名其妙——它们本质上是两边对同一行做了不同演进。git merge还分两种推进方式如果当前分支是目标分支的后代能直接快进Git 默认会做 fast-forward也就是把当前分支指针直接向前挪到目标 commit不产生新的合并节点git merge --no-ff则会强制生成一个合并提交保留这里曾经分叉过的历史轨迹。我个人的默认偏好是--no-ff尤其当功能分支存在多条提交时这个合并节点会让后续的git log --graph非常清晰。3.2 rebase 是重演历史不是修改历史很多人把 rebase 和修改历史画等号然后吓得不敢用。准确地说rebase 是在找共同祖先之后把你这条分支上的每个 commit 逐个取下来在目标分支的最新 HEAD 上重新落一次。因为是重演所以同一个功能、同样的 diff最终生成的 commit 哈希会完全不一样——从这个意义上看它确实重写了你自己分支的历史但它没有修改任何已有的远端提交。那你到底该在什么时候 rebase我只有一个核心标准拿这串提交当私人物品时随便用一旦这些提交已经被推向共享远程、别人可能基于它开分支了就别再 rebase 和 force push。典型的安全用法是本地开发几天后git fetch发现main已经前进了用git rebase main把自己的提交搬到最新 base 上改完冲突后得到一个干净的线性历史。这样将来合并回main时几乎可以 fast-forwardreview 的同事看提交历史也能顺着一条线往下读。如果团队协作里你发现别人 rebase 了共享分支并强推最稳定的自救方式是拿到对方的最终版本放弃自己基于旧版本做的本地分歧提交用 cherry-pick 把真正有价值的改动重新移植过去。3.3 cherry-pick精准移植单个提交如果说 rebase 是把整个分支重放到新基地cherry-pick就是只挑某个 commit 的补丁拿到当前分支上应用。它的内部机制其实也是一次三路合并只不过目标不是一条分支的尾部而是某个指定的 commit。用法非常简单先找到那个提交的哈希然后git switch dev执行git cherry-pick abc1234。这个命令最常见的场景是线上 hotfix 在main上修完需要把同一个修复带到当前发版分支或者一个独立提交写得很漂亮别的分支也想复用。注意 cherry-pick 会产生新的 commit它不等于移动原提交而是把变更复制了一份。如果你发现连续要挑一堆提交那还不如直接 merge 整个分支来的高效。3.4 冲突处理先搞清楚冲突是什么再选工具遇到冲突时不要慌先安抚自己的第一反应完了代码乱了。其实冲突文件里被、、包围的区块就是两侧分支在同一位置的差异。你需要做的是打开文件逐段判断该保留左、保留右还是取两者的某种结合然后git add标记解决最后完成 merge 或 rebase。如果想偷懒可以组合git mergetool把双方版本放到可视化的三方合并工具里例如 VSCode、Beyond Compare、Meld 都可以配置。我更推荐在有条件时让工具帮你看但不要只会用工具真正的高级技巧是git rerere重用已记录的冲突解决方案。你如果提前开启了git config --global rerere.enabled true之后同一处冲突第二次出现Git 会自动沿用你上次的选择。这个功能特别适合 rebase 中途反复在同一位置被同一批上游改动干扰的场景。初次接触可以不用但知道有这枚暗器会让你在冲突迷宫里多一条安全绳。3.5 一张表说清选择逻辑场景推荐操作核心理由私有功能分支同步最新 maingit rebase main保持个人提交线性重放冲突可控共享分支把功能合入主干git merge --no-ff feature/xxx保留合并拓扑便于反向追踪与 revert单条 hotfix 移植到发版分支git cherry-pick hash精准选择不夹带无关改动想让功能分支历史干干净净成一坨git merge --squash或变基交互式rebase -i合并前压缩提交粒度更合理这张表不是铁律但它覆盖了我经手的大部分分支合并决策。剩下容我去斟酌的基本都和这段历史有没有被共享相关。4. 远程分支协作的完整链路fetch、push、跟踪关系与认证细节4.1 本地分支和远程分支是两套平行宇宙本地分支的名字你天天用但很多人没意识到main和origin/main是两个不同的东西。origin/main是“远程跟踪分支”它只忠诚地记录上次我从远程看到的 main 长什么样本地任何操作都不会改动它除非你执行git fetch、git pull或git push。git clone时Git 会帮你创建本地main并自动设置与origin/main的跟踪关系所以你第一次git pull、git push无需指定远程参数。但你自己新建的分支默认是不跟踪任何远程分支的第一次 push 时要么git push -u origin dev要么在 IDE 里勾选“Set upstream”否则后续 push 就得总是带上参数。这个两套平行宇宙的意识一旦建立你就能理解为什么本地 commit 了很久却 push 不上去也能理解为什么同事说我已经推了而你 fetch 后还是看不到——fetch 只是更新了远程跟踪引用真正合并到工作区是另一回事。4.2 fetch、pull、pull --rebase 怎么用简单说git fetch只把远程分支的最新 commit 拉到本地并更新origin/*完全不碰你的工作区和当前分支git pull等于git fetch加git merge默认会把远程新提交合并进来可能产生一个 merge 提交git pull --rebase则相当于 fetch 后把自己的本地提交 rebase 到远程最新提交之上。那到底该用哪种我的习惯是个人开发、自己的分支尽量用git pull --rebase让历史保持线性多人协作、共同开发一个 feature 分支时反而用默认的git pullmerge更好因为如果每个人都 rebase 再强推很容易互相踩踏。rebase不是灵丹妙药它的适用前提是你对自己的提交有完全控制权。4.3 push 失败、强行推送与协作规范push 被拒大概是团队新人最常遇见的问题之一。报错信息里通常写着non-fast-forward在很多情况下这是因为远端分支已经多出了你没有的提交你的本地历史已经不是它的直接祖先。解法很简单pull或 pull --rebase把新提交取回来解决冲突再 push。如果偏偏有人用了git push --force那就要谨慎了。--force是无条件的覆盖如果覆盖前没有拉取最新状态别人的提交可能直接消失。所以今天我更推荐git push --force-with-lease它会先检查远端分支是否还是你上次 fetch 时的样子如果不是就拒绝强推相当于给强推加了一层保险。我之前还见过一个低级但很真实的失误有同事把本地一个很旧的分支直接强推到远程把线上维护分支刷回一个月前最后只能靠 reflog 和重置恢复。所以我要在这里苦口婆心一句永远不要在共享分支上使用无条件的 force push。如果你必须重写历史请先写 release notes 通知团队让每个人暂停操作。4.4 SSH 认证、Token 与日常远程配置排查热词里反复出现“ssh 认证失败 git”其实排查链路非常固定。先用git remote -v看看远端 URL 是不是gitgithub.com:user/repo.git这种 SSH 形态如果 URL 没问题再测ssh -T gitgithub.com看能不能正常打招呼最后ssh-add -l确认本地密钥是否已被 ssh-agent 加载。常见的失败原因无非是密钥生成后没加进 agent或者用户换电脑后没有把公钥加到托管平台。HTTPS 方式呢现在主流托管平台都支持“个人访问令牌Personal Access Token”。你把用户名换成 token 的持有者密码位置填 token 本身就能推送。而且 token 可以设置权限范围和有效期比把账号密码明文写在配置里安全得多。如果你发现 Git 老是提示认证失败、又莫名其妙记住了一个过期密码那多半是凭据缓存作怪。Windows 上可以去系统的凭据管理器里删掉对应条目macOS 则是钥匙串Linux 则看你用的 credential helper 是什么。清理完缓存重新认证一次往往就恢复正常了。还有一件安全方面的事顺便说一下如果你用 Git 做服务器端部署千万别把仓库的.git目录放到 Web 容器可直接访问的静态目录下。这些年我处理过几次源码泄露事故源头都是.git目录被顺手暴露在站点根目录别人用工具一扫就能把整个历史拉走。该有的访问权限控制和防火墙规则不要省。5. 分支管理高频踩坑现场 amend、revert、worktree、submodule 与文件级疑难5.1 commit --amend 的正确使用边界很多人把git commit --amend当“改一下提交说明”的快捷键这没错但有个巨大的坑藏在里面amend 不是修改原提交而是把当前暂存区内容与上一次提交合并生成一个全新的提交对象旧提交会被替换掉。所以如果你已经 push 过上次提交再 amend 并强推别人基于旧提交做的工作就悬在半空。我的使用规范是--amend只用于我还没推送、或者确定只有我在用的本地提交上。比如“刚提交完又发现漏了一个文件/写错了注释”这时候git add 漏掉的文件 git commit --amend可以把两次改动合并成一次干净提交。如果提交已经进了共享分支那宁可多提交一次“fix typo”也别去动历史。5.2 revert公共分支上最安全的后悔药当提交已经在共享分支上你想撤销它首选的永远是git revert hash。revert 不会删除任何历史它只是生成一个“反向变更”的新提交把目标提交引入的改动抵消掉。这么做的好处是整个提交历史是追加式的所有协作者 pull 后都能平滑同步不会出现强制推送带来的集体混乱。我实际工作里经常遇到这样的场景某个 feature 分支合并进 main 后发现逻辑有重大问题线上需要紧急回滚。这时候我直接git revert merge的提交哈希干净利落地把本次合并的变动全部推翻。注意 revert 一个合并提交时可能需要-m参数指定保留哪一边这个细节最好在测试分支上先演练一遍免得在线上手忙脚乱。5.3 分支乱掉时怎么优雅恢复分支彻底搞乱的情况一般有两种一种是你本地提交一坨乱麻但远程还很干净另一种是远程分支被搞坏了必须恢复。前一种最简单的办法是不要试图在乱分支上反复 rebase 修补直接基于远程状态重建一条干净分支git switch -c feature-clean origin/feature然后把有价值的工作用 cherry-pick 逐个搬过来。后一种呢如果远程分支被错误地 reset 或 push --force且没过多久就发现改用的武器是git reflog。reflog 记录的是本地所有引用移动的历史包括 reset、commit、merge、rebase 之前的指针位置。顺藤摸瓜找到那个丢失的 commit 哈希就能在本地创建一个分支把现场抢救回来再合规地恢复远程。我处理过的最惊险一次就是依赖 reflog 把一天前误删的发布分支完整拉回来了。记住Git 很少真的丢数据它只是把引用指向了别处。5.4 worktree 与分支的区别一个仓库并行多个工作目录很多人看到热词里问“git worktree 和 git branch 有什么区别”这里一次性讲清。git branch只是生成一个指向 commit 的引用同一时间你传统上只能在一个工作目录里检查一个分支而git worktree则允许同一个仓库同时开出多个工作目录每个目录可以 check out 不同的分支共享同一个.git对象库但各自拥有独立的索引和工作区。举个例子我在main上开发突然线上炸了需要马上切到hotfix分支修东西。普通流程是先 stash 或提交当前半成品切走改完切回来。用 worktree 则可以直接git worktree add ../hotfix-xxx -b hotfix/urgent在旁边的目录里另开一条战场原地修复完就能部署。这体验就像给平行宇宙各自开了个独立浏览器窗口一样。用完后记得git worktree remove ../hotfix-xxx并把关联分支处理掉别让垃圾目录堆在那里影响判断。5.5 submodule能不用就尽量不用如果你在代码库里看到git submodule先掂量一下它真的必要吗submodule 的用途是把另一个独立仓库以固定 commit 的形式嵌进当前仓库适合那种你要锁死版本的外部组件的场景。但一旦用上麻烦事接踵而至clone 下来还要git submodule update --init --recursive才能把子模块内容拉全每次子模块上游更新主仓库又得更新 pointer协作时不小心还会出现“我明明改了子模块怎么 push 不上去”的尴尬。我的观点是能用包管理器解决的依赖问题就不要用 submodule。比如前端依赖交给 npm、后端依赖交给 go mod 或 maven它们对版本的解析和锁定机制比 submodule 成熟得多。只有那种没有包管理器、又需要严格版本对齐的私有代码库submodule 才值得入场。5.6 分支周边的常见疑难与文件级坑最后统一处理几个高频疑难每一个我都亲眼在团队环境里见过。大文件提交失败Git 本身不适合管理大文件默认的传输协议和对象库对几百 MB 的二进制文件很不友好经常出现推送超时或仓库体积爆炸。正确的解决方式是引入 Git LFSLarge File Storage用git lfs track *.psd把大文件后缀交给 LFS 管理仓库里只存指针真正的文件放在 LFS 存储端。CRLF 行尾符问题Windows 和 Linux/macOS 的换行符不同Git 有时会在你不知情的情况下转来转去导致 diff 里出现成片无意义改动。解法是在仓库根目录放一份.gitattributes明确指定* textauto eollf这类规则让所有协作者使用同一套行尾策略。这个文件应该在项目早期就加上越晚处理代价越大。.gitignore 设置无效十有八九是因为你要忽略的文件已经被 Git 跟踪了。.gitignore只管“没被跟踪”的文件对已经 add 过的文件毫无作用。处理办法是git rm --cached file把它从索引里移除但不删物理文件再加进.gitignore提交一次即可。Git Bash 报 open /dev/null or dup failed: no such file or directory这个报错看上去像仓库损坏其实多数是 Windows 下 Git Bash 的资源或环境问题常见于在非交互式 shell、管道嵌套或临时目录异常时执行 Git 命令。我的处理建议是换个新的 Git Bash 窗口重试升级 Git for Windows 到较新版本关掉可能拦截句柄的安全软件。这通常不是仓库数据的问题不用去git fsck兴师动众。在 IDE 里合并分支以 IDEA 为例右下角的分支按钮会列出本地所有分支选择目标分支后可以直接 Merge into Current 或 Rebase Current onto Selected。IDE 的好处是冲突时能弹出图形化的三方对比窗口适合不习惯命令行的同事。但 IDE 的坏处是会把很多底层细节藏起来建议新人至少在命令行做过几次 merge 和 rebase再回到图形界面否则出了问题很难排查。这些年带团队我发现凡是能把分支原理想明白的人后面用 Git 几乎不会再犯方向性错误。他们知道 rebase 不是魔法、reset 不是删除、force push 不是特权而是各自都有明确代价的操作。我最后的建议就一条把 GitHub 官方那篇“Git branching”的旧文档和git help branch的原文各读一遍不会比少刷几条短视频更费时间但回报绝对超值。分支管理这门手艺说到底就是把“指针移动”和“历史拓扑”两件事刻进肌肉记忆里剩下的全是细节而细节真的会决定你在协作中的体验。