git分支是我这些年用得多、也被同事问得最多的命令组之一。很多人会用十几个命令却不知道一个分支本质上是什么于是每次“切到别的分支文件凭空消失”“合并时冲突一片飘红”“想把另一个分支的某个提交搬过来却不知道从何下手”就卡住了。这篇文章我按真实开发场景把 git分支常用操作全部串一遍从创建、切换、合并、清理到跨分支搬运提交、多分支并行开发、常见报错排查原理和实操放一起讲争取你看完能直接上手遇到问题也能自己排查。适合谁看刚被名词劝退的新人、用了几年 Git 但只会 add/commit/push 的熟手以及需要同时维护多个需求分支、经常在分支之间搬代码的开发者。1. 分支到底是个什么东西先搞明白设计逻辑1.1 分支的本质其实就是一行指针很多人学 Git 时把分支想象成“文件夹的副本”这个印象很害人。实际上一个分支在存储层面只是一个名字对应某一次提交的哈希值。Git 里的提交对象像一条项链每个提交都记录着上一个提交的哈希一路串下去A - B - C。分支 main 就是一张写着最新提交哈希的便利贴贴在 C 上你在 main 上提交一个新东西便利贴挪到 D你在 feature 分支上提交feature 的便利贴挪到 E仅此而已。因为只是便利贴Git 创建分支的成本极低git branch feature只是在对象库里写一个新名字不用复制任何目录也不会让项目磁盘占用翻倍。很多人纠结 “本地建分支是不是要先把代码复制一份”“切分支是不是要全量更新”这些误解都源于没看懂指针模型。理解了这一行指针后面所有问题都容易解释为什么切换分支那么快、为什么删除分支不丢提交、为什么合并会产生分叉历史。这也是 Git 和 SVN 最本质的差异之一。SVN 的分支通常意味着目录复制切换分支要同步整个工作副本Git 的分支只是标记切换只是在几个提交之间移动指针并把工作区内容做增量调整。这个差异后面第 6 章还会再展开。1.2 本地分支和远程分支的区别很多人栽在这里本地分支就是你当前工作目录对应的工作分支比如 main、feature。远程跟踪分支比如 origin/main它并不是远程仓库里真实存在的分支而是你本地维护的一份“远程状态快照”。每次执行git fetch或git pull本地才会把这艘快照更新每次git push会先把本地提交对象补进本地对象库再上传到远端更新远程仓库的真实分支。有个常见的坑有人直接git checkout origin/main然后在这个“远端分支”上提交结果提交完发现不落在本地 main 上逻辑全乱了。正确做法是基于远程跟踪分支创建本地分支git checkout -b feature origin/feature或者直接git switch -c feature origin/feature。团队多人协作时如果两个人同时改同一个分支别人已经推送了新提交你本地落后这时候需要先 fetch 看到对方提交再通过 merge 或 rebase 把本地更新过去而不是拿着旧状态盲目覆盖推送。很多 “push rejected” 的报错根源就在“本地远程快照过期”。1.3 分支管理里最常见的三个误区第一个误区切换分支后代码“不见了”以为代码丢了。其实 Git 只是按照当前分支的提交内容重新还原工作区。文件只存在于另一个分支切换后它自然不在当前目录里切回那个分支就又回来了。真正需要注意的是未提交的修改Git 会阻止你切分支或者会尝试把它们带到新分支严重时产生一堆诡异的冲突。所以切换前先git status看一眼是好习惯。第二个误区删除分支等于删除提交。删除只是撕掉便利贴提交对象仍然在 Git 对象库里只要还能通过 reflog 或其他分支引用到就能找回来。这也是为什么git branch -D虽然带提示但并没有想象中那么可怕前提是你记得及时处理。第三个误区分支必须完全合并之后才能删除。实际上用git branch -D可以强制删除任何分支只要我确定那些提交不再需要。但强制删除前至少想清楚一件事这个分支上的成果是彻底废弃了还是只是暂时没合并如果是后者先合并或者先 push 到远端再删否则同事那边可能会跑出“引用不存在的提交”这类问题。2. 日常分支操作增删改查的完整命令手册2.1 创建和切换分支checkout、switch、branch 到底该用哪个Git 新版命令逐步把checkout拆成了switch和restore聚焦点的思想是对的。虽然git checkout -b老玩家已经肌肉记忆但新项目用 switch 语义更清楚不容易误操作。git branch feature创建分支但不切换。git switch -c feature创建并切换等价于checkout -b feature。git switch feature切换到已存在的分支。git switch -切回上一个分支版本较老的 Git 用checkout -。在 IDEA 里切换分支点右下角分支名弹出本地和远程分支列表选目标再 Checkout 即可VSCode 则在左下角点击当前分支名打开分支面板选择。这里有个特别常见的难题用 IDEA 打开一个复制出来的主项目找不到像原项目那样的分支列表。核心原因是你复制的是某个处于特定分支的检出版本分支引用通常还在.git里。解决方式是在 IDEA 右下角的分支面板里展开 Remote Branches找到要切的分支Checkout 成新的本地分支如果整个.git目录在复制时被忽略或删除了那就不是“切换分支”的问题而是这个目录已经变成一个没有 Git 元数据的普通文件目录需要用 VCS 重新从远端拉取项目。很多人在这上面绕半天其实就是复制项目时带了不该删的.git。2.2 查看分支和远程状态别再用眼睛数分支了分支多了以后靠记忆不靠谱该熟练用这几个命令git branch -a列出所有本地分支和远程跟踪分支。git branch -vv查看本地分支和远程跟踪分支的对应关系还会显示领先或落后多少提交。git status永远的第一反应当前分支、暂存状态、相对远程的领先落后都在这里。git log --oneline --graph --all用字符画查看提交和分支图比很多 GUI 工具的视图直观。一个很容易被忽略的操作是 fetch 和 pull 的边界。git pull等于fetch再merge如果你只是想拿到远端分支的最新状态又不想动当前工作区内容直接git fetch才是正确姿势。远程分支被别人删掉之后本地还保留着过期的origin/xxx用git fetch --prune origin或提前设置git config fetch.prune true每次 fetch 自动清理逻辑上已经不存在的远程跟踪分支。VSCode 里处理也是这样Source Control 视图的同步操作本质上就包含 prune如果用了 GitLens仓库视图里删掉没用的远端跟踪分支更直观。但注意git branch -rd origin/xxx只是删除本地的那条远程跟踪引用并不会删除真正的远程分支真正的远端删除还是得git push origin --delete xxx。2.3 删除与清理本地、远程和VSCode的配合删除本地分支用git branch -d feature只有在分支已合并到当前分支时才会干净删除如果分支上有未合并提交Git 会拒绝这时用git branch -D feature可以强制删除。删除远程分支用git push origin --delete feature对应老写法是git push origin :feature意思是“推送一个空引用覆盖远端分支”效果等价。VSCode 的用户可以在命令面板CtrlShiftP输入 “Git: Delete Branch” 选择要删的分支。新版 VSCode 还会在源代码管理侧边栏的同步提示里出现“已删除分支”点击即可同步清理远端已经不存在的跟踪分支。这些按钮背后的命令还是上面那两条理解了命令GUI 就只是换了个壳。我自己的习惯是每天开工先跑一次git fetch --prune让所有过期的远端引用暴露出来删分支前再跑git branch -vv看一眼有没有未合并提示。分支命名乱、合并状态不明时绝不手滑使用-D大杀器。3. 分支合并与同步merge、rebase、amend 到底怎么选3.1 merge 分支合并的心智模型merge 是最常用的同步手段。在 main 上执行git merge featureGit 会找两个分支的分叉点然后把 feature 上的改动与 main 的改动合并生成一个新的合并提交 M。如果 main 从分叉点之后就没有新提交Git 会默认走快进模式fast-forward直接把 main 挪到 feature 的提交上不生成额外的合并节点历史完全线性。要不要保留合并节点看场景。团队协作中我通常建议对功能分支合并使用--no-ffgit merge --no-ff feature即使 feature 只有一个提交也保留一个合并提交将来不管是看历史、回滚到整个功能、还是找责任人都更清楚。反过来长期同步主干时反而允许 fast-forward减少没意义的合并节点。这里没有唯一答案选哪种取决于团队对“历史整洁度”和“可追溯性”的偏好。IDEA 里执行“分支A合并到分支B”很常见先切到目标分支 B再在分支面板里选中来源分支 A选择 Merge into Current。顺序反了会把改动合到错误的地方我见过不止一次。VSCode 配合 GitLens 也能在仓库视图右键分支完成 Merge但熟悉命令行之后能准确知道每一步在做什么不容易被 UI 误导。3.2 rebase 变基和 commit --amend 的使用边界rebase 是把当前分支的提交“重新安放”到另一个分支的最新提交之上让分叉变成直线。比如git switch feature后执行git rebase mainfeature 上的提交会被一个一个拔下来重新落到 main 的最新提交后面。这种做法好处是合并回 main 时历史干净坏处是 feature 上所有提交的哈希都会改变因为它们的父提交变了。所以业内有一条黄金法则不要对已推送到公共远程的分支执行 rebase。一旦你重写了历史别人本地还在用旧哈希引用这些提交下一次 pull 必然乱套。个人分支、未推送的本地提交可以放心 rebase多人共用的集成分支一律用 merge。git commit --amend用于修改最后一次本地提交。最常见的两种用法是补文件或改提交说明git add -A git commit --amend --no-edit--no-edit表示不修改提交说明只是把新内容并入上一次提交如果想连说明一起改直接git commit --amend会打开编辑器。需要强调amend 同样会改变提交哈希和 rebase 一个道理已经推送的提交不要 amend。如果确定是自己的单人分支改了之后强推也要提前和同事打招呼否则就是经典事故。3.3 冲突解决的实战套路冲突不是 Bug是 Git 在守信用的表现。三方合并时Git 只看当前分支提交、对方分支提交、以及共同祖先提交。如果两边恰好改了同一个文件的同一处Git 不知道该听谁的只能把选择权交给你。冲突内容会标记成这样 HEAD 本地保留的代码对方分支的代码feature/xxx实战处理流程先git status看冲突文件清单逐个文件打开搜索冲突标记留下正确的版本、删除不需要的段落并把标记行全部删干净。确认后git add 文件。如果是 merge 过程中冲突最后git commit生成合并提交如果是 rebase 过程中冲突先git add再git rebase --continue想放弃这次 rebase 则用git rebase --abort。踩过几次坑之后我总结出三条原则。第一合并前先看一眼两个分支各自改了哪些文件脑子里有谱再动手。第二一次提交尽量小小提交冲突范围也就小出问题好定位。第三IDE 自带的三窗口合并工具比肉眼盯尖括号靠谱IDEA 的 Diff/Merge 对话框可以左右选择内容效率远高于纯文本编辑。3.4 merge 与 rebase 的选择参考场景推荐方式原因功能分支合回开发主干merge --no-ff保留功能完整合并节点便于整体回滚从主干拉最新到自己的功能分支rebase历史保持线性后续合回主干更干净多人共用的集成分支merge避免重写已共享的历史本地还没推送的提交rebase或amend可以放心整理不影响别人只想搬某一个提交过来cherry-pick见第 4 章4. 将其他分支的部分功能迁移过来cherry-pick 和 revert4.1 cherry-pick 精准搬运只要一个提交日常里经常遇到这样的需求同事在另一个分支上已经修好了某个问题主分支还没合并或者一次功能开发拆成了好多个提交但我只需要其中某一个。如果直接用 merge会把整个分支都带过来不稳定也没必要。git cherry-pick就是为了解决“只把某个提交复制到当前分支”这个场景而生的。git switch main git cherry-pick abc1234abc1234是目标提交的哈希也可以是分支引用形式比如git cherry-pick feature~2代表搬 feature 分支倒数第二个提交。执行后 Git 会把那个提交涉及的改动在当前分支上重放成功则自动生成一个新提交如果有冲突就按第 3 章的冲突流程处理之后git cherry-pick --continue继续。如果想把一段连续提交搬过来可以给一个范围git cherry-pick start^..end这会包含从 start 之后到 end 之间的所有提交。个人强烈建议搬移时加-x参数git cherry-pick -x abc1234它会在新提交信息里自动一行 “cherry picked from commit …”将来追溯来源时省很多事。团队协作中这条记录比什么都值钱。4.2 从一个分支搬移代码的注意事项cherry-pick 不是万能药。如果两个分支已经分叉很久、共同基础很少同一次改动在不同分支上重放时可能没有冲突提示却产生逻辑上的错漏换句话说代码层面能 apply 成功不代表业务层面还成立。搬移前建议先把目标分支同步到和源分支相近的状态或者用git diff对比两个提交的实际改动内容再决定要不要搬。还有一种场景功能已经混在多个提交里没法用 cherry-pick 精确拆分只想把某个文件在另一个分支上的最终状态拿过来。可以用补丁方式git diff main feature -- src/only-file.ts patch.diff git apply patch.diff或者更直接但少用于生产环境git checkout feature -- src/only-file.ts。注意后者会把当前分支该文件直接覆盖成 feature 的状态不带任何合并判断操作前确认清楚别把当前改动冲掉。4.3 撤销与回滚别把 revert 和 reset 搞混撤销提交有两条完全不同的路线。git revert是生成一个新提交来抵消目标提交的影响历史被完整保留新提交的信息里还会说明撤销了谁。这种方式安全适合任何分支尤其适合已经推送到远端的公共提交。git reset是让当前分支指针往回退直接改写历史适合本地还没推送的提交。阅读理解三者差别git reset --soft HEAD~1退回上一提交所有改动还留在暂存区。git reset --mixed HEAD~1退回上一提交改动回到工作区但取消暂存是默认行为。git reset --hard HEAD~1直接丢弃改动危险操作回不了头除非靠 reflog。如果要撤销的是一次合并提交事情会更复杂一点因为 merge commit 有两个父提交。git revert -m 1 mergeHash表示从主线视角撤销这次合并保留功能分支那边已经带出来的新提交-m 2则是从被合并分支视角撤销通常用得少。不写-m直接 revert 一个合并提交Git 会抱怨“不知道要撤销哪一条线”。公共分支上我从不推荐用reset --hard去“纠正”别人已经看到的提交。哪怕你是唯一提交人也一样可能影响他人的本地引用。公共历史出问题时宁可多用一次 revert 换一个“无害但正确”的新提交。5. 多分支同时开发和疑难杂症从 worktree 到 reflog5.1 git worktree一套代码同时开多个分支环境的正确打开方式前端或后端项目经常有“需求 A 在开发线上那边一个 hotfix 又必须马上改”的场景。以前最土的办法是复制一份目录但那不是同一个仓库的逻辑上下文remote 和分支关联都得手动处理切来切去还容易乱。Git 从 2.15 开始支持 worktree允许同一个仓库在多个目录同时检出不同分支git worktree add ../project-hotfix hotfix cd ../project-hotfix git status执行后你会多出一个project-hotfix目录里面已经是 hotfix 分支的独立工作副本并且和原目录共享同一套 Git 对象库。在原目录继续开发 feature 完全不受影响两边并行构建、并行测试都行。想关闭这个辅助目录git worktree remove ../project-hotfix git worktree listworktree list可以查看所有已关联的工作目录。注意一点同一个分支不能被两个 worktree 同时 checkout这是设计上为了防止两边提交互相覆盖。删除 worktree 前先确保目标目录里没有尚未提交的改动也没有被 IDE 占用否则 remove 会报错。这个功能用完就回不去了尤其适合需要同时维护多个发布版本的人。5.2 用 stash 临时保存改动切分支前没提交怎么办正在 feature 分支改到一半线上出了紧急问题必须先切到 hotfix 分支。直接切过去要么被 Git 拦下来要么带着一坨未提交改动过去制造混乱。正确姿势是git stash把工作区和暂存区改动打包存起来把工作区还原到当前 HEAD 的状态。常用子命令git stash save wip: 登录模块给暂存加说明方便后期辨认。git stash list查看暂存列表。git stash pop恢复栈顶暂存并从栈中移除。git stash apply恢复栈顶暂存但保留栈条目适合同一份改动想在多个分支套用。git stash drop丢弃指定的暂存条。需要注意git stash默认不包含未跟踪的新文件想连新建文件一起存用git stash -u。恢复时如果当前分支已经变动很大stash pop也可能产生冲突按照普通冲突流程解决就行千万不要用git checkout .去“清理”那会把暂存内容一并冲掉。5.3 误删分支和提交恢复reflog 才是最稳的后悔药git reflog记录的是 HEAD 指针在这台机器上走过的每一步移动历史。分支本身可以删掉但 reflog 里仍保留 HEAD 曾经指过的位置所以误删分支、误 reset 之后都能靠它把指针救回来。git reflog git checkout -b recover commit-hash只要那次提交还躺在对象库里没有被git gc真正清理就能通过这条命令重新拉回一个分支。前端开发者在 VSCode 里也能通过命令面板执行 Git: View History 看到部分历史但 reflog 这类恢复操作命令行比图形界面稳很多。经历了“重置回退后发现代码找不回来”的惊吓之后我现在每次在不完全确认的情况下使用reset --hard都会先记住当前 HEAD 哈希或者干脆先创建一个 backup 分支成本极低收益极高。6. 分支规范和常见问题速查从报错到设计6.1 项目分支策略小团队与大团队的务实选择不是所有项目都适合教科书里的 Git Flow。小团队或者迭代快的项目我建议主干开发模式main 分支始终保持可用功能分支现场搭建命名feature/xxx、bugfix/xxx完成即合并并删除最长分支生命周期不超过几天。长期维护 main 加一条 hotfix 分支就足够应付大多数产品节奏。规模扩大后再引入 develop、release 这种层级配合权限控制。但不管哪种策略有两件事值得用规则固定下来。第一受保护分支尤其是 main不允许直接提交所有变更走 Pull Request 或 Merge Request经过评审合并第二分支名尽量包含需求或缺陷单号比如feature/PAY-123-sms否则事后翻历史基本靠猜。我见过很多团队分支管理混乱不是不懂命令而是忘了定规矩。6.2 git 和 SVN 的分支差别为什么我们愿意用几步完成分支合并SVN 是集中式版本控制基于目录设计。创建分支往往意味着目录复制切换分支要更新整个工作副本合并的历史追踪也比较粗。Git 是分布式版本控制每个开发者本地都有一份完整仓库分支只是一个指针所以创建、切换、合并分支都极快哪怕离线也能提交。从 SVN 转到 Git最需要转变的三个认知是本地提交是常态不要憋一大坨才 commit分支便宜到可以随便建不要舍不得开远程不是唯一真理在本地整理好提交记录再推上去。尤其是第三点在 Git 里commit --amend、rebase -i、cherry-pick这些“改历史”操作之所以能安全使用全依赖“远程不是你唯一的家”这个前提。6.3 常见错误速查表报错一fatal: not a git repository (or any of the parent directories): .git原因基本就两类你在一个没有.git的目录里执行了 Git 命令或者仓库的.git目录被误删了。先确认当前目录是否正确再往上级目录找有没有.git。如果项目本身没问题大概率只是终端路径不对切回项目根目录再执行。报错二git : 无法将“git”项识别为 cmdlet、函数、脚本文件或可运行程序的名称这是 Windows PowerShell 找不到 git 命令本质是没安装 Git或者 Git 没有加入 PATH 环境变量。解决方式下载安装 Git for Windows安装时勾选 “Add to PATH”装完重开终端跑git --version验证。如果你用 git-bash 能跑但 PowerShell 不能跑也基本是 PATH 配置问题手动把 Git 的 cmd 目录加进环境变量即可。报错三SSH 认证失败类似gitgithub.com: Permission denied (publickey)这说明远端平台不认你本地这把 SSH 钥匙。解决流程先用ssh-keygen -t ed25519 -C your_email生成密钥对把.pub的内容添加到平台账户的 SSH Keys 里然后ssh -T git对应域名测试。如果公司内部的 GitLab 还连不上注意检查 SSH 端口和地址是否有特殊配置必要时在~/.ssh/config里写清楚 Host、HostName、User、Port。报错四git push 每次都要求输入账号密码或者想清除保存过的账号密码HTTPS 方式下Git 会通过凭据管理器保存密码。Windows 上常见的清理路径是控制面板 - 用户帐户 - 凭据管理器 - Windows 凭据找到 git 相关条目删除命令行里也可以执行git credential-manager erase来抹掉对应凭证。改用 SSH 密钥或者 Personal Access Token 当密码之后这类烦恼能少很多。6.4 提交信息与 commit 规范分支只是载体真正让项目活得久的是提交信息。建议简单模板feat(module): description。比如feat(auth): 增加手机号登录。这个习惯在cherry-pick和 merge 之后尤其重要因为分支删光以后能读的就只剩提交历史。每次写提交时把自己当成三个月后的读者信息多交代一句后面就少猜一次。最后分享一个我踩了很多年坑才养成的习惯无论用什么工具分支操作前先确认“我现在在哪、我要去哪、我要带什么”。很多事故不是命令记错了而是没有意识到分支本质是指针随手一个 checkout 就切走随手一个 reset 就回退。这几年我用 Git 最多的场景不是 push 和 commit反而是 fetch、rebase、cherry-pick 和 worktree 这些“整理类”操作它们决定了仓库是干净还是一团乱麻。如果你刚接触 Git先把这篇里的常用命令挑几个贴到键盘旁边用熟了再去翻更厚的文档会没那么玄乎。