1. 为什么分支是Git最被低估的核心能力很多人用Git用了两三年日常操作还是只有git add、git commit、git push这三板斧分支对他们来说就是个合并代码用的东西。我见过不少开发者整个团队共用一条master分支所有人往上怼代码出了问题就回滚回滚完再怼循环往复。这种用法不是不行但它把Git最强大的能力浪费了。分支的本质是什么你可以把它理解成一条时间线。每次提交就是在这条时间线上打一个节点。创建分支就是在当前节点上分出一条新的时间线两条线各自往前走互不干扰。这个互不干扰才是关键——它意味着你可以在一条线上做实验、改bug、开发新功能而另一条线始终保持稳定可用。我刚开始接触Git的时候也觉得分支是个高级功能等用熟了才发现它其实是最基础的操作。你新建一个仓库Git默认就给你创建了一个分支现在通常叫main或master你每次提交都在这个分支上。所以你不是要不要用分支的问题而是怎么用好分支的问题。这篇文章会从分支的底层原理讲起把创建分支的各种方式、分支管理的实战技巧、团队协作中的分支策略、以及我这些年踩过的坑全部摊开来讲。不管你是刚学Git的新手还是用了几年但一直没系统梳理过分支的开发者应该都能从中找到对自己有用的东西。2. 分支的底层原理指针、快照与HEAD2.1 分支不是文件夹的拷贝很多人对分支有个误解以为创建一个分支就是把当前所有代码复制一份。不是的。Git的分支本质上只是一个指向某个提交对象的轻量级可移动指针。创建分支的操作实际上就是新建一个指针让它指向当前的提交节点。这个设计的好处是创建一个分支几乎不消耗任何额外空间速度也是瞬间完成的。不管你仓库里有多少文件、多大体积git branch命令都是毫秒级返回。因为Git只是写了一个41字节的文件40个字符的SHA-1哈希值加一个换行符仅此而已。我用一个具体的例子来说明。假设你的仓库目前有三次提交提交历史是这样的A - B - C (main)main是一个指针指向提交C。提交C里包含了一个指向提交B的指针提交B又指向提交A。每个提交对象都包含了当时整个项目的完整快照Git用内容寻址的方式存储相同内容不会重复存储。现在你执行git branch featureGit做了什么它只是新建了一个叫feature的指针也指向提交CA - B - C (main, feature)就这么简单。没有复制文件没有创建目录只是多了一个指针。2.2 HEAD是什么HEAD是一个特殊的指针它指向你当前所在的分支。你可以把它理解成你现在站在哪条时间线上的标记。当你执行git checkout feature或git switch feature时Git做两件事把HEAD指向feature分支然后把工作目录的内容更新成feature分支所指向的提交的快照。这里有个概念叫分离头指针状态detached HEAD就是HEAD直接指向了某个提交而不是分支。这种状态在查看历史提交、做临时实验时有用但如果你在这种状态下做了提交然后切换走了那些提交可能会丢失——因为它们没有分支指针引用它们Git的垃圾回收机制最终会把它们清理掉。提示如果你在分离头指针状态下做了提交想保留这些工作可以立刻创建一个新分支指向当前提交git branch new-branch-name。这样就不会丢了。2.3 提交时发生了什么当你在某个分支上执行git commit时Git会做以下几步创建一个新的提交对象包含当前暂存区的快照、作者信息、提交信息以及一个指向父提交的指针。把当前分支的指针移动到新提交上。HEAD保持不变仍然指向当前分支只是分支指向的提交变了。用图来表示在main分支上提交D之后A - B - C - D (main) (feature 仍指向 C)这就是分支的生长过程。每次提交当前分支的指针就往前挪一步。不同分支各自独立地往前挪互不影响。理解了这一点你就能明白为什么Git的分支操作这么快、这么轻量。它不像某些老式版本控制工具那样需要复制整个目录它只是在操作指针。3. 创建分支的几种方式与适用场景3.1 最基础的创建git branch创建一个分支最直接的方式就是git branch feature-login这条命令会在当前提交上创建一个名为feature-login的新分支。注意创建完之后你仍然停留在原来的分支上不会自动切换过去。这是新手最容易困惑的地方——创建了分支但发现自己还在main上。如果你想创建并立即切换过去可以用git checkout -b feature-login或者Git 2.23版本之后引入的新命令git switch -c feature-logingit switch是专门用来切换分支的命令把切换分支和恢复文件这两个功能从git checkout里拆开了。我个人现在更推荐用git switch因为语义更清晰不容易误操作。3.2 基于指定提交创建分支有时候你需要基于某个历史提交来创建分支而不是当前最新的提交。比如你发现某个功能在三次提交之前是正常的想从那个点拉一个分支来排查问题git branch debug-branch abc1234其中abc1234是目标提交的哈希值短哈希就行。也可以用相对引用git branch debug-branch HEAD~3HEAD~3表示当前提交往前数三个提交。这种用法在排查回归问题时特别有用。3.3 基于远程分支创建本地分支团队协作中你经常需要把远程仓库的某个分支拉到本地来git fetch origin git branch feature-remote origin/feature-remote或者更常见的做法是直接切换过去Git会自动创建本地分支并建立追踪关系git switch feature-remote如果远程有多个仓库比如同时协作了多个fork你需要指定具体的远程名称git switch -c local-name upstream/feature-branch3.4 从标签创建分支标签tag通常用来标记发布版本。有时候你需要基于某个发布版本创建分支来做热修复git branch hotfix-v1.2 v1.2.0这种场景在维护多个版本的产品线时非常常见。比如你同时维护v1.x和v2.x两个大版本v1.x上发现了安全漏洞就需要从v1.x的最新标签拉一个hotfix分支来修复。3.5 创建孤儿分支孤儿分支orphan branch是一个没有父提交的分支相当于重新开始一条全新的历史线。这种分支的典型用途是存放项目文档、GitHub Pages静态页面等让它们和代码历史完全分开git checkout --orphan docs创建孤儿分支后工作目录里的文件仍然在但它们都处于未追踪状态。你需要先清空暂存区再重新添加需要的文件git rm -rf --cached . # 然后添加你需要的文件 git add README.md git commit -m 初始化文档分支孤儿分支在实际项目中使用频率不高但在特定场景下非常有用。比如一个项目想同时维护代码和独立的文档站点又不想让文档的提交历史污染代码历史孤儿分支就是最佳选择。4. 分支切换的细节与常见误区4.1 切换分支时工作目录发生了什么当你执行git switch other-branch时Git会做以下几件事检查当前工作目录和暂存区是否有未提交的更改。如果没有冲突把HEAD指向目标分支。把工作目录的文件更新为目标分支所指向的提交的快照。更新暂存区。这个过程是覆盖式的——目标分支里有什么文件你的工作目录就变成什么文件。如果当前分支有某个文件而目标分支没有那个文件会被删除。这也是为什么切换分支前最好确保工作区是干净的。4.2 未提交的更改会怎样这是新手最容易踩的坑。分几种情况情况一修改的文件在两个分支中内容相同。比如你在main上修改了README.md但还没提交然后切换到feature分支而feature分支的README.md和main的完全一样。这种情况下Git会保留你的修改直接切换成功。情况二修改的文件在两个分支中内容不同。Git会拒绝切换报错说Your local changes would be overwritten by checkout。这时候你有几个选择提交更改、暂存更改git stash、或者放弃更改。情况三新增的文件。如果你新建了一个文件但还没提交切换分支时这个文件会跟着你走因为Git不追踪未追踪的文件。注意切换分支前养成git status看一眼的习惯能帮你避免很多意外。如果确实需要带着未提交的更改切换用git stash暂存一下是最稳妥的做法。4.3 git checkout和git switch的区别在Git 2.23之前git checkout承担了太多职责切换分支、恢复文件、创建分支、检出特定提交。功能太多导致容易误操作——比如你想切换分支结果不小心写成了git checkout -- somefile把文件修改给撤销了。Git 2.23引入了两个新命令来拆分这些功能git switch专门用于切换和创建分支。git restore专门用于恢复文件。我现在的习惯是切换分支一律用git switch恢复文件一律用git restore只有在需要兼容老版本Git的时候才用git checkout。这样能有效减少误操作。5. 分支管理查看、重命名与删除5.1 查看分支的正确姿势git branch列出所有本地分支当前分支前面会有一个星号。加上-v参数可以看到每个分支的最新提交git branch -v加上-a可以看到包括远程分支在内的所有分支git branch -a加上--merged和--no-merged可以筛选出已经合并和尚未合并到当前分支的分支git branch --merged git branch --no-merged这两个命令在清理分支时特别有用。--merged列出的分支说明它们的提交已经全部包含在当前分支里了可以安全删除。--no-merged列出的分支还有未合并的工作删除前要三思。5.2 重命名分支重命名当前分支git branch -m new-name重命名其他分支git branch -m old-name new-name如果重命名的是已经推送到远程的分支还需要在远程做相应操作先删除远程旧分支再推送新分支。git push origin --delete old-name git push origin new-name然后让本地分支追踪新的远程分支git branch -u origin/new-name5.3 删除分支的时机与风险删除一个已经合并的分支git branch -d feature-done如果分支还没有合并Git会拒绝删除并提示你。如果你确认不需要这个分支了可以用大写D强制删除git branch -D feature-abandoned强制删除的风险在于如果这个分支上有未合并的提交删除后这些提交可能会被垃圾回收除非你记得它们的哈希值。所以强制删除前最好用git log feature-abandoned确认一下里面有没有还需要的内容。提示一个实用的习惯是删除分支前先看看它和当前分支的差异git log --oneline main..feature-abandoned。这会列出feature-abandoned上有但main上没有的提交。确认这些提交确实不需要了再删除。5.4 恢复误删的分支如果不小心删除了一个分支还有救。Git会记录分支指针的移动历史可以通过git reflog找到被删除分支的最后一次提交git reflog在输出中找到类似abc1234 HEAD{5}: commit: 完成了登录功能的记录然后用那个哈希值重建分支git branch recovered-branch abc1234reflog默认保留90天对于可达对象或30天对于不可达对象所以只要不是太久之前删的基本都能找回来。这个机制救过我好几次。6. 团队协作中的分支策略选择6.1 为什么需要分支策略一个人写代码的时候分支怎么用都行。但团队协作就不一样了——多个人同时往一个仓库推代码如果没有约定好的分支使用规则很快就会乱成一锅粥。分支策略本质上是一套团队约定规定了什么情况下创建什么类型的分支、分支从哪里拉、合并到哪里去、什么时候删除。常见的分支策略有好几种没有绝对的好坏关键看团队规模、发布节奏和项目特点。6.2 主干开发加发布分支这是比较轻量的策略。团队所有人日常在main分支上开发需要发布版本时从main拉一个release分支在release分支上做测试和bug修复稳定后再合并回main并打标签。main: A - B - C - D - E - F \ / release: R1 - R2 - R3这种策略适合持续部署的团队main分支始终保持可发布状态。缺点是如果发布周期长release分支和main的差异会越来越大合并时容易冲突。6.3 功能分支工作流每个新功能都从main拉一个功能分支开发完成后通过Pull Request合并回main。这是目前最流行的做法配合代码审查工具使用效果很好。main: A - B - C - D - E \ / feature: F1 - F2功能分支的生命周期通常比较短几天到一两周。分支存活时间越长合并时冲突的风险越大。我个人的经验是一个功能分支最好不要超过三天不合并否则就要考虑把它拆小。6.4 Git Flow的适用与不适用Git Flow是一套比较重的分支模型定义了main、develop、feature、release、hotfix五种分支类型每种都有明确的用途和合并规则。它在2010年被提出时非常流行但现在很多团队已经不再采用了。Git Flow的问题在于太复杂。对于大多数Web应用来说持续部署的模式下根本不需要develop分支和release分支。但对于有明确版本发布周期的软件比如客户端软件、嵌入式系统Git Flow仍然是一个合理的选择。我的建议是不要一上来就套用Git Flow。先从简单的功能分支工作流开始遇到具体问题了再考虑引入更复杂的策略。工具是为人服务的不是反过来。6.5 分支命名规范不管用什么策略分支命名最好有个统一规范。常见的做法是用前缀区分分支类型前缀用途示例feature/新功能开发feature/user-loginbugfix/修复非紧急bugbugfix/cart-total-errorhotfix/紧急修复线上问题hotfix/payment-crashrelease/发布准备release/v2.1.0docs/文档更新docs/api-referencerefactor/代码重构refactor/order-service这样命名的好处是git branch列出来的时候一目了然而且可以用通配符批量操作。比如删除所有已合并的feature分支git branch --merged | grep feature/ | xargs git branch -d7. 分支操作中的典型问题与排查思路7.1 切换分支时报错local changes would be overwritten这个报错的意思是你当前有未提交的修改而目标分支上这些文件的内容和当前分支不同切换过去会覆盖你的修改。排查步骤先git status看看哪些文件有修改。如果这些修改是你要保留的git stash暂存起来切换分支后再git stash pop。如果这些修改不要了git restore file放弃修改。如果修改需要提交到当前分支先git add和git commit。我遇到过一个比较隐蔽的情况修改了一个文件但那个文件在.gitignore里所以git status看不到。切换分支时Git却报错了。这种情况需要用git status --ignored才能看到被忽略的文件。7.2 合并分支时冲突了怎么办冲突是分支操作中不可避免的。当两个分支修改了同一个文件的同一部分时Git无法自动决定保留哪个版本就会产生冲突。处理冲突的流程git status会列出所有冲突文件标记为both modified。打开冲突文件会看到类似这样的标记 HEAD 当前分支的代码 目标分支的代码 feature-branch手动编辑文件决定最终保留什么内容删除冲突标记。git add标记为已解决。git commit完成合并。提示处理冲突时不要只看冲突标记的那几行。有时候冲突的根源在文件的其他位置需要理解两边的修改意图才能正确解决。我习惯在解决冲突前先看看两个分支各自的提交信息了解每边改了什么、为什么改。7.3 分支追踪关系丢失有时候你会发现git push或git pull不工作了提示no tracking information。这是因为本地分支和远程分支的追踪关系断了。修复方法git branch -u origin/branch-name或者推送时指定git push -u origin branch-name追踪关系丢失的常见原因包括远程分支被删除后重建、远程仓库地址变更、手动修改了Git配置等。7.4 误在错误的分支上提交这个错误太常见了你以为自己在feature分支上结果提交到了main分支。如果还没推送修复起来很简单# 在main上撤销最后一次提交但保留修改 git reset --soft HEAD~1 # 切换到正确的分支 git switch feature-branch # 重新提交 git commit -m 提交信息如果已经推送了就需要用git revert来创建一个反向提交而不是用reset改写历史。改写已推送的历史会影响其他协作者除非你确定没有其他人基于这个提交工作否则不要这么做。8. 我这些年积累的分支使用心得8.1 保持分支短命一个分支从创建到合并的时间越短出问题的概率越小。我给自己定的规矩是功能分支不超过三天。如果三天做不完说明这个功能太大应该拆成多个小功能每个小功能一个分支。短命分支的好处是显而易见的冲突少、审查快、回滚容易。一个存活了两周的分支合并时可能要解决几十个冲突代码审查的人看到那么多改动也会头疼。8.2 提交前先拉取在功能分支上工作了一段时间后准备合并回main之前先做一次git fetch origin git rebase origin/main或者git merge origin/main这样可以在合并前解决冲突而不是等到发起Pull Request时才发现冲突。我个人的偏好是用rebase因为它能保持提交历史的线性但rebase会改写提交历史如果分支已经推送并且有其他人基于它工作就不要用rebase。8.3 用分支做代码实验分支的另一个重要用途是做实验。当你有一个不确定的想法不知道能不能work可以拉一个实验分支去试。试成功了就合并试失败了就删掉main分支完全不受影响。这种用法给了我很大的安全感。以前不敢随便改代码怕改坏了回不去。有了分支之后我可以放心大胆地尝试各种方案因为我知道main分支始终是安全的。8.4 定期清理分支远程仓库里堆积大量已合并的分支是很常见的。这些分支不仅让git branch -a的输出变得很长还会让新人感到困惑。我通常每个月清理一次# 查看已合并到main的远程分支 git branch -r --merged origin/main # 删除远程已合并的分支 git push origin --delete branch-name有些团队会配置自动删除策略Pull Request合并后自动删除源分支。这个做法值得推广。8.5 分支保护规则对于main这样的关键分支最好设置保护规则禁止直接推送、必须通过Pull Request合并、必须通过CI检查、必须有人审查通过。这些规则可以在代码托管平台上配置能有效防止误操作。我见过最惨的事故是有人直接往main推了一个有问题的提交导致线上服务挂了两个小时。如果设置了分支保护规则这个提交根本进不了main。分支这个功能说简单也简单说深也深。简单在于核心概念就那几个指针、提交、HEAD。深在于怎么把这些概念组合成适合团队的工作流怎么在灵活性和稳定性之间找到平衡。我自己的体会是不要追求一步到位先从功能分支工作流开始用起来遇到问题了再调整。用得多了自然就找到适合自己团队的方式了。 
长河君 · 2026/10/21 23:47:10 · 阅读 1.2k Git分支从原理到实战：创建、管理与团队协作策略
1. 为什么分支是Git最被低估的核心能力很多人用Git用了两三年日常操作还是只有git add、git commit、git push这三板斧分支对他们来说就是个合并代码用的东西。我见过不少开发者整个团队共用一条master分支所有人往上怼代码出了问题就回滚回滚完再怼循环往复。这种用法不是不行但它把Git最强大的能力浪费了。分支的本质是什么你可以把它理解成一条时间线。每次提交就是在这条时间线上打一个节点。创建分支就是在当前节点上分出一条新的时间线两条线各自往前走互不干扰。这个互不干扰才是关键——它意味着你可以在一条线上做实验、改bug、开发新功能而另一条线始终保持稳定可用。我刚开始接触Git的时候也觉得分支是个高级功能等用熟了才发现它其实是最基础的操作。你新建一个仓库Git默认就给你创建了一个分支现在通常叫main或master你每次提交都在这个分支上。所以你不是要不要用分支的问题而是怎么用好分支的问题。这篇文章会从分支的底层原理讲起把创建分支的各种方式、分支管理的实战技巧、团队协作中的分支策略、以及我这些年踩过的坑全部摊开来讲。不管你是刚学Git的新手还是用了几年但一直没系统梳理过分支的开发者应该都能从中找到对自己有用的东西。2. 分支的底层原理指针、快照与HEAD2.1 分支不是文件夹的拷贝很多人对分支有个误解以为创建一个分支就是把当前所有代码复制一份。不是的。Git的分支本质上只是一个指向某个提交对象的轻量级可移动指针。创建分支的操作实际上就是新建一个指针让它指向当前的提交节点。这个设计的好处是创建一个分支几乎不消耗任何额外空间速度也是瞬间完成的。不管你仓库里有多少文件、多大体积git branch命令都是毫秒级返回。因为Git只是写了一个41字节的文件40个字符的SHA-1哈希值加一个换行符仅此而已。我用一个具体的例子来说明。假设你的仓库目前有三次提交提交历史是这样的A - B - C (main)main是一个指针指向提交C。提交C里包含了一个指向提交B的指针提交B又指向提交A。每个提交对象都包含了当时整个项目的完整快照Git用内容寻址的方式存储相同内容不会重复存储。现在你执行git branch featureGit做了什么它只是新建了一个叫feature的指针也指向提交CA - B - C (main, feature)就这么简单。没有复制文件没有创建目录只是多了一个指针。2.2 HEAD是什么HEAD是一个特殊的指针它指向你当前所在的分支。你可以把它理解成你现在站在哪条时间线上的标记。当你执行git checkout feature或git switch feature时Git做两件事把HEAD指向feature分支然后把工作目录的内容更新成feature分支所指向的提交的快照。这里有个概念叫分离头指针状态detached HEAD就是HEAD直接指向了某个提交而不是分支。这种状态在查看历史提交、做临时实验时有用但如果你在这种状态下做了提交然后切换走了那些提交可能会丢失——因为它们没有分支指针引用它们Git的垃圾回收机制最终会把它们清理掉。提示如果你在分离头指针状态下做了提交想保留这些工作可以立刻创建一个新分支指向当前提交git branch new-branch-name。这样就不会丢了。2.3 提交时发生了什么当你在某个分支上执行git commit时Git会做以下几步创建一个新的提交对象包含当前暂存区的快照、作者信息、提交信息以及一个指向父提交的指针。把当前分支的指针移动到新提交上。HEAD保持不变仍然指向当前分支只是分支指向的提交变了。用图来表示在main分支上提交D之后A - B - C - D (main) (feature 仍指向 C)这就是分支的生长过程。每次提交当前分支的指针就往前挪一步。不同分支各自独立地往前挪互不影响。理解了这一点你就能明白为什么Git的分支操作这么快、这么轻量。它不像某些老式版本控制工具那样需要复制整个目录它只是在操作指针。3. 创建分支的几种方式与适用场景3.1 最基础的创建git branch创建一个分支最直接的方式就是git branch feature-login这条命令会在当前提交上创建一个名为feature-login的新分支。注意创建完之后你仍然停留在原来的分支上不会自动切换过去。这是新手最容易困惑的地方——创建了分支但发现自己还在main上。如果你想创建并立即切换过去可以用git checkout -b feature-login或者Git 2.23版本之后引入的新命令git switch -c feature-logingit switch是专门用来切换分支的命令把切换分支和恢复文件这两个功能从git checkout里拆开了。我个人现在更推荐用git switch因为语义更清晰不容易误操作。3.2 基于指定提交创建分支有时候你需要基于某个历史提交来创建分支而不是当前最新的提交。比如你发现某个功能在三次提交之前是正常的想从那个点拉一个分支来排查问题git branch debug-branch abc1234其中abc1234是目标提交的哈希值短哈希就行。也可以用相对引用git branch debug-branch HEAD~3HEAD~3表示当前提交往前数三个提交。这种用法在排查回归问题时特别有用。3.3 基于远程分支创建本地分支团队协作中你经常需要把远程仓库的某个分支拉到本地来git fetch origin git branch feature-remote origin/feature-remote或者更常见的做法是直接切换过去Git会自动创建本地分支并建立追踪关系git switch feature-remote如果远程有多个仓库比如同时协作了多个fork你需要指定具体的远程名称git switch -c local-name upstream/feature-branch3.4 从标签创建分支标签tag通常用来标记发布版本。有时候你需要基于某个发布版本创建分支来做热修复git branch hotfix-v1.2 v1.2.0这种场景在维护多个版本的产品线时非常常见。比如你同时维护v1.x和v2.x两个大版本v1.x上发现了安全漏洞就需要从v1.x的最新标签拉一个hotfix分支来修复。3.5 创建孤儿分支孤儿分支orphan branch是一个没有父提交的分支相当于重新开始一条全新的历史线。这种分支的典型用途是存放项目文档、GitHub Pages静态页面等让它们和代码历史完全分开git checkout --orphan docs创建孤儿分支后工作目录里的文件仍然在但它们都处于未追踪状态。你需要先清空暂存区再重新添加需要的文件git rm -rf --cached . # 然后添加你需要的文件 git add README.md git commit -m 初始化文档分支孤儿分支在实际项目中使用频率不高但在特定场景下非常有用。比如一个项目想同时维护代码和独立的文档站点又不想让文档的提交历史污染代码历史孤儿分支就是最佳选择。4. 分支切换的细节与常见误区4.1 切换分支时工作目录发生了什么当你执行git switch other-branch时Git会做以下几件事检查当前工作目录和暂存区是否有未提交的更改。如果没有冲突把HEAD指向目标分支。把工作目录的文件更新为目标分支所指向的提交的快照。更新暂存区。这个过程是覆盖式的——目标分支里有什么文件你的工作目录就变成什么文件。如果当前分支有某个文件而目标分支没有那个文件会被删除。这也是为什么切换分支前最好确保工作区是干净的。4.2 未提交的更改会怎样这是新手最容易踩的坑。分几种情况情况一修改的文件在两个分支中内容相同。比如你在main上修改了README.md但还没提交然后切换到feature分支而feature分支的README.md和main的完全一样。这种情况下Git会保留你的修改直接切换成功。情况二修改的文件在两个分支中内容不同。Git会拒绝切换报错说Your local changes would be overwritten by checkout。这时候你有几个选择提交更改、暂存更改git stash、或者放弃更改。情况三新增的文件。如果你新建了一个文件但还没提交切换分支时这个文件会跟着你走因为Git不追踪未追踪的文件。注意切换分支前养成git status看一眼的习惯能帮你避免很多意外。如果确实需要带着未提交的更改切换用git stash暂存一下是最稳妥的做法。4.3 git checkout和git switch的区别在Git 2.23之前git checkout承担了太多职责切换分支、恢复文件、创建分支、检出特定提交。功能太多导致容易误操作——比如你想切换分支结果不小心写成了git checkout -- somefile把文件修改给撤销了。Git 2.23引入了两个新命令来拆分这些功能git switch专门用于切换和创建分支。git restore专门用于恢复文件。我现在的习惯是切换分支一律用git switch恢复文件一律用git restore只有在需要兼容老版本Git的时候才用git checkout。这样能有效减少误操作。5. 分支管理查看、重命名与删除5.1 查看分支的正确姿势git branch列出所有本地分支当前分支前面会有一个星号。加上-v参数可以看到每个分支的最新提交git branch -v加上-a可以看到包括远程分支在内的所有分支git branch -a加上--merged和--no-merged可以筛选出已经合并和尚未合并到当前分支的分支git branch --merged git branch --no-merged这两个命令在清理分支时特别有用。--merged列出的分支说明它们的提交已经全部包含在当前分支里了可以安全删除。--no-merged列出的分支还有未合并的工作删除前要三思。5.2 重命名分支重命名当前分支git branch -m new-name重命名其他分支git branch -m old-name new-name如果重命名的是已经推送到远程的分支还需要在远程做相应操作先删除远程旧分支再推送新分支。git push origin --delete old-name git push origin new-name然后让本地分支追踪新的远程分支git branch -u origin/new-name5.3 删除分支的时机与风险删除一个已经合并的分支git branch -d feature-done如果分支还没有合并Git会拒绝删除并提示你。如果你确认不需要这个分支了可以用大写D强制删除git branch -D feature-abandoned强制删除的风险在于如果这个分支上有未合并的提交删除后这些提交可能会被垃圾回收除非你记得它们的哈希值。所以强制删除前最好用git log feature-abandoned确认一下里面有没有还需要的内容。提示一个实用的习惯是删除分支前先看看它和当前分支的差异git log --oneline main..feature-abandoned。这会列出feature-abandoned上有但main上没有的提交。确认这些提交确实不需要了再删除。5.4 恢复误删的分支如果不小心删除了一个分支还有救。Git会记录分支指针的移动历史可以通过git reflog找到被删除分支的最后一次提交git reflog在输出中找到类似abc1234 HEAD{5}: commit: 完成了登录功能的记录然后用那个哈希值重建分支git branch recovered-branch abc1234reflog默认保留90天对于可达对象或30天对于不可达对象所以只要不是太久之前删的基本都能找回来。这个机制救过我好几次。6. 团队协作中的分支策略选择6.1 为什么需要分支策略一个人写代码的时候分支怎么用都行。但团队协作就不一样了——多个人同时往一个仓库推代码如果没有约定好的分支使用规则很快就会乱成一锅粥。分支策略本质上是一套团队约定规定了什么情况下创建什么类型的分支、分支从哪里拉、合并到哪里去、什么时候删除。常见的分支策略有好几种没有绝对的好坏关键看团队规模、发布节奏和项目特点。6.2 主干开发加发布分支这是比较轻量的策略。团队所有人日常在main分支上开发需要发布版本时从main拉一个release分支在release分支上做测试和bug修复稳定后再合并回main并打标签。main: A - B - C - D - E - F \ / release: R1 - R2 - R3这种策略适合持续部署的团队main分支始终保持可发布状态。缺点是如果发布周期长release分支和main的差异会越来越大合并时容易冲突。6.3 功能分支工作流每个新功能都从main拉一个功能分支开发完成后通过Pull Request合并回main。这是目前最流行的做法配合代码审查工具使用效果很好。main: A - B - C - D - E \ / feature: F1 - F2功能分支的生命周期通常比较短几天到一两周。分支存活时间越长合并时冲突的风险越大。我个人的经验是一个功能分支最好不要超过三天不合并否则就要考虑把它拆小。6.4 Git Flow的适用与不适用Git Flow是一套比较重的分支模型定义了main、develop、feature、release、hotfix五种分支类型每种都有明确的用途和合并规则。它在2010年被提出时非常流行但现在很多团队已经不再采用了。Git Flow的问题在于太复杂。对于大多数Web应用来说持续部署的模式下根本不需要develop分支和release分支。但对于有明确版本发布周期的软件比如客户端软件、嵌入式系统Git Flow仍然是一个合理的选择。我的建议是不要一上来就套用Git Flow。先从简单的功能分支工作流开始遇到具体问题了再考虑引入更复杂的策略。工具是为人服务的不是反过来。6.5 分支命名规范不管用什么策略分支命名最好有个统一规范。常见的做法是用前缀区分分支类型前缀用途示例feature/新功能开发feature/user-loginbugfix/修复非紧急bugbugfix/cart-total-errorhotfix/紧急修复线上问题hotfix/payment-crashrelease/发布准备release/v2.1.0docs/文档更新docs/api-referencerefactor/代码重构refactor/order-service这样命名的好处是git branch列出来的时候一目了然而且可以用通配符批量操作。比如删除所有已合并的feature分支git branch --merged | grep feature/ | xargs git branch -d7. 分支操作中的典型问题与排查思路7.1 切换分支时报错local changes would be overwritten这个报错的意思是你当前有未提交的修改而目标分支上这些文件的内容和当前分支不同切换过去会覆盖你的修改。排查步骤先git status看看哪些文件有修改。如果这些修改是你要保留的git stash暂存起来切换分支后再git stash pop。如果这些修改不要了git restore file放弃修改。如果修改需要提交到当前分支先git add和git commit。我遇到过一个比较隐蔽的情况修改了一个文件但那个文件在.gitignore里所以git status看不到。切换分支时Git却报错了。这种情况需要用git status --ignored才能看到被忽略的文件。7.2 合并分支时冲突了怎么办冲突是分支操作中不可避免的。当两个分支修改了同一个文件的同一部分时Git无法自动决定保留哪个版本就会产生冲突。处理冲突的流程git status会列出所有冲突文件标记为both modified。打开冲突文件会看到类似这样的标记 HEAD 当前分支的代码 目标分支的代码 feature-branch手动编辑文件决定最终保留什么内容删除冲突标记。git add标记为已解决。git commit完成合并。提示处理冲突时不要只看冲突标记的那几行。有时候冲突的根源在文件的其他位置需要理解两边的修改意图才能正确解决。我习惯在解决冲突前先看看两个分支各自的提交信息了解每边改了什么、为什么改。7.3 分支追踪关系丢失有时候你会发现git push或git pull不工作了提示no tracking information。这是因为本地分支和远程分支的追踪关系断了。修复方法git branch -u origin/branch-name或者推送时指定git push -u origin branch-name追踪关系丢失的常见原因包括远程分支被删除后重建、远程仓库地址变更、手动修改了Git配置等。7.4 误在错误的分支上提交这个错误太常见了你以为自己在feature分支上结果提交到了main分支。如果还没推送修复起来很简单# 在main上撤销最后一次提交但保留修改 git reset --soft HEAD~1 # 切换到正确的分支 git switch feature-branch # 重新提交 git commit -m 提交信息如果已经推送了就需要用git revert来创建一个反向提交而不是用reset改写历史。改写已推送的历史会影响其他协作者除非你确定没有其他人基于这个提交工作否则不要这么做。8. 我这些年积累的分支使用心得8.1 保持分支短命一个分支从创建到合并的时间越短出问题的概率越小。我给自己定的规矩是功能分支不超过三天。如果三天做不完说明这个功能太大应该拆成多个小功能每个小功能一个分支。短命分支的好处是显而易见的冲突少、审查快、回滚容易。一个存活了两周的分支合并时可能要解决几十个冲突代码审查的人看到那么多改动也会头疼。8.2 提交前先拉取在功能分支上工作了一段时间后准备合并回main之前先做一次git fetch origin git rebase origin/main或者git merge origin/main这样可以在合并前解决冲突而不是等到发起Pull Request时才发现冲突。我个人的偏好是用rebase因为它能保持提交历史的线性但rebase会改写提交历史如果分支已经推送并且有其他人基于它工作就不要用rebase。8.3 用分支做代码实验分支的另一个重要用途是做实验。当你有一个不确定的想法不知道能不能work可以拉一个实验分支去试。试成功了就合并试失败了就删掉main分支完全不受影响。这种用法给了我很大的安全感。以前不敢随便改代码怕改坏了回不去。有了分支之后我可以放心大胆地尝试各种方案因为我知道main分支始终是安全的。8.4 定期清理分支远程仓库里堆积大量已合并的分支是很常见的。这些分支不仅让git branch -a的输出变得很长还会让新人感到困惑。我通常每个月清理一次# 查看已合并到main的远程分支 git branch -r --merged origin/main # 删除远程已合并的分支 git push origin --delete branch-name有些团队会配置自动删除策略Pull Request合并后自动删除源分支。这个做法值得推广。8.5 分支保护规则对于main这样的关键分支最好设置保护规则禁止直接推送、必须通过Pull Request合并、必须通过CI检查、必须有人审查通过。这些规则可以在代码托管平台上配置能有效防止误操作。我见过最惨的事故是有人直接往main推了一个有问题的提交导致线上服务挂了两个小时。如果设置了分支保护规则这个提交根本进不了main。分支这个功能说简单也简单说深也深。简单在于核心概念就那几个指针、提交、HEAD。深在于怎么把这些概念组合成适合团队的工作流怎么在灵活性和稳定性之间找到平衡。我自己的体会是不要追求一步到位先从功能分支工作流开始用起来遇到问题了再调整。用得多了自然就找到适合自己团队的方式了。