企业官网建设流程全解析

1. 分支清理前的准备工作

1.1 先看清仓库现状再动手

删除分支这件事，最忌讳的就是“凭记忆操作”。很多时候我们觉得某个分支没用了，结果一删，发现上面还躺着没合并的提交，或者某个功能还指着这个分支继续迭代。所以动手之前，我强烈建议你先把仓库的完整状态摸清楚。

第一步，先看一眼本地都有哪些分支。我习惯用这条命令：

git branch -vv

-vv比单纯的git branch多展示两部分信息：每个本地分支跟踪的远程分支是谁，以及分支相对于远程分支是领先（ahead）还是落后（behind）。比如输出里出现[origin/feat/login: ahead 3]，就说明这个本地分支比远程分支多了 3 个提交，删之前你得想清楚这 3 个提交是不是真的不要了。

第二步，看远程分支的状态。有些远程分支其实已经被合并进主干，只是没人清理，一直挂在服务器上。用这条命令可以列出所有远程分支：

git branch -r

如果你想看每个远程分支的最后提交时间和提交人，可以在命令后面加上--verbose，不过这只能看到分支指针的提交信息，看不到“最后活跃时间”。想看时间的话，可以这么干：

git for-each-ref --format='%(refname:short) %(committerdate:relative)' refs/remotes

输出类似origin/feat/old-login 3 months ago，一眼就能看出哪些分支已经“凉了”。

第三步，也是最重要的一步：确认分支是否已经被合并。这里有两个常用命令：

# 查看哪些本地分支已经合并进当前分支 git branch --merged # 查看哪些本地分支还没有合并 git branch --no-merged

同样的，远程分支也可以用类似方式过滤，比如git branch -r --merged。这个检查非常关键，它能直接告诉你哪些分支删了不心疼，哪些分支删了会丢提交。

另外提醒一句，git branch --merged是相对于“当前所在分支”来判断的。如果你当前在main分支上，它列出的就是已经合并进main的分支。如果你想以develop为基准判断，可以先切过去再执行，或者用git branch --merged develop直接指定基准分支。

1.2 用图表理清本地与远程分支的对应关系

很多新手在删分支时最大的困惑不是命令不会敲，而是搞不清楚“本地分支”和“远程分支”到底是什么关系。这里我用一个简单的类比来解释。

可以把远程仓库想象成公司服务器上的共享文件夹，本地分支是你自己电脑上的工作副本。你本地新建一个分支并提交代码，远程仓库是不知道的，除非你执行git push把这个分支推送到远程。反过来，别人推到远程的新分支，你本地也看不到，除非执行git fetch拉取最新的远程分支引用。

所以删除分支时要区分四种情况：

看到这里可能有人会问：“本地分支不是会自动跟踪远程分支吗？删了远程的，本地的为什么还在？”这是因为本地分支本质上是存在于你本地.git目录里的一个引用文件，远程分支的删除不会自动同步到你的本地。它们之间的“跟踪关系”更多是一种映射，而不是强绑定。所以删完远程分支后，本地分支需要你手动处理。

还有一点容易忽略：git fetch默认不会删除本地已经“失效”的远程跟踪分支。所谓失效，是指远程分支已经被别人删除，但你本地的origin/xxx引用还在。这时候可以执行：

git fetch --prune

这个命令会清理掉本地仓库中那些“远程已经不存在”的远程跟踪分支引用。配合git branch -r再检查一遍，你会看到列表干净了不少。

2. 本地分支删除的完整姿势

2.1 安全删除与强制删除的区别

本地分支删除是日常使用频率最高的操作，但很多人只会一个git branch -d，遇到删不掉的情况就直接上-D，其实两者背后的逻辑差别很大。

git branch -d是“安全删除”。执行时 Git 会检查这个分支是否已经被合并进当前分支（或者它跟踪的上游分支）。如果已经合并，直接删除；如果没有合并，Git 会拒绝删除，并提示：

error: The branch 'xxx' is not fully merged.

这个保护机制非常实用。试想一下，你花了三天写了一个功能分支，但因为某些原因没有合并，如果误删了，整个工作成果就全没了。虽然 Git 的 reflog 还能抢救一下，但对不熟悉 reflog 的人来说基本等于数据丢失。所以能用-d就不要用-D，这是我在团队里反复强调的习惯。

git branch -D是“强制删除”，它跳过合并检查，不管分支是否合并直接删。使用场景很明确：你确定这个分支的代码已经不需要了，或者代码已经通过其他方式保留了。但用了-D，就意味着你主动放弃 Git 的保护，责任自己扛。

我见过不少同事因为合并 PR 时选择了“Squash and merge”，导致功能分支和主干分支的实际提交历史不一致，结果git branch -d怎么都删不掉。这种时候确实只能用-D，因为 Squash 合并之后，功能分支上的原始提交并没有出现在主干历史里，Git 的合并检查自然不通过。但前提是你要确认 PR 确实已经被合入，代码已经进了主干，否则别轻易用-D。

2.2 删除分支时提示 not fully merged 怎么办

这个提示算是 Git 最常见的“劝退”信息之一。遇到它，先别急着上-D，按下面的顺序排查：

第一步，确认当前在哪个分支上。如果你现在就在要删除的分支上，Git 会拒绝删除：“cannot delete branch ... checked out”。先切换到其他分支，比如git checkout main或git switch main。

第二步，确认分支是否真的已经合并。执行：

git branch --merged

如果这个分支不在列表里，说明它确实有未合并的提交。接下来要判断这些提交是否还需要：

• 如果功能已经完成并通过 PR 合入，但用的是 Squash merge，Git 的提交历史里找不到原分支的提交记录，所以判定为“未合并”。这种可以直接用-D。
• 如果功能确实没完成，或者完成了但还没合入，那就别删，需要先把提交合并过去再说。
• 如果分支里的功能已经废弃，确认无保留价值，可以用-D。

第三步，如果你不确定分支里有哪些独有提交，可以用下面这条命令查看：

git log --onetime --graph 主干分支名..要删除的分支名

注意这里的..是两点语法，作用是把“要删除的分支有、而主干分支没有”的提交列出来。看一下这些提交的内容，你就心里有数了。如果输出为空，说明所有提交都已经在主干分支上了，这时用git branch -d就能安全删除。

2.3 批量删除本地分支的技巧

如果你本地堆积了大量已经合并的旧分支，一条一条删太累了。这时候可以借助 shell 的循环能力：

git branch --merged | grep -v '^\*' | grep -v 'main' | xargs git branch -d

这条命令的思路是：先列出所有已合并分支，排除当前分支（^\*匹配的是带星号的那一行），再排除主干分支名，最后用xargs把剩余分支名传给git branch -d执行删除。

注意，这个命令需要一定的辨别能力。grep -v 'main'只是简单做了字符串匹配，如果你的其他分支名里也包含main字样，比如feat/maintenance，会被误伤。所以执行前先跑一下前半段，看看输出结果是否符合预期：

git branch --merged | grep -v '^\*' | grep -v 'main'

确认没问题再追加xargs那部分。批量操作最怕的就是“自动化了一堆错误的事”，多看一眼输出花不了几秒钟。

如果你用的是 PowerShell（Windows 环境），写法稍有不同：

git branch --merged | Select-String -NotMatch '^\*|main' | ForEach-Object { $_.Line.Trim() } | ForEach-Object { git branch -d $_ }

不过说实话，Windows 下我更推荐直接在 VS Code 或 IDE 的源代码管理面板里手动删除，可视化操作反而更安全。

3. 远程分支删除与同步清理

3.1 远程分支删除的正确命令

远程分支删除统一用git push配合--delete参数，这是目前最标准、最通用的方式：

git push origin --delete 分支名

这条命令执行后，远程仓库里对应的分支引用会被删除，同时 Git 会输出类似这样的提示：

- [deleted] feat/old-login

有些老教程会让你用git push origin :分支名这种写法，它的原理是“推送一个空引用到远程分支，从而实现删除”。虽然效果一样，但可读性太差，新手看了完全不知道在干嘛。我现在统一建议用--delete，语义清晰，也更不容易打错。

删除远程分支时有个容易忽略的点：如果你本地当前的分支恰好跟踪的就是这个远程分支，执行删除后，本地 Git 会提醒你跟踪关系失效了，但不会自动帮你把这个分支切走。所以删除前先看一眼自己当前在哪个分支，如果你就在这个要删的本地分支上，先切到其他分支再操作。

另外，git push origin --delete只会删除远程分支，不会动你本地的同名分支。如果想彻底清理，还需要单独删本地分支。

3.2 清理远程已删除分支的本地残留引用

这是大多数团队协作场景里最容易遇到的“脏状态”。你在自己电脑上执行git branch -r，能看到一堆origin/feat/xxx，但实际上有些远程分支早就被同事删了。这些残留引用不会自动消失，它们静静地躺在你本地的.git/refs/remotes/目录里。

解决这个问题靠git fetch --prune，或者更完整的写法：

git fetch --prune origin

加上--prune参数后，Git 在拉取远程引用时，会自动删除本地那些“远程已经不存在”的远程跟踪分支。执行完再跑一遍git branch -r，你会发现列表干净了。

这里再推荐一个设置，让你的日常fetch始终自动清理：

git config --global fetch.prune true

设置之后，以后每次git fetch都会自动带上--prune的效果。这个配置对团队协作非常有用，尤其是在多人频繁创建和删除分支的项目里。我个人建议所有 Git 用户都配一下，属于“配置一次、长期受益”的典型。

还有一个小技巧：如果在某些 IDE 里看到很多“幽灵分支”，比如 VS Code 的源代码管理面板里列着一堆已经不存在的远程分支，大概率就是本地没有做 prune。执行一次git fetch --prune，然后刷新面板，基本就能解决。

3.3 远程分支删除后本地分支怎么处理

删除远程分支不等于删除了本地分支，这两者是独立的。很多人在远程分支删除后发现自己本地还有同名分支，这个分支还处于“无人跟踪”的状态。

处理方式因人而异：

• 如果这个分支以后还要继续用，比如你想在本地继续开发，或者重新推送到远程，那就保留本地分支，用它作为基础继续工作。
• 如果远程分支删除意味着整个功能彻底下线，本地分支也可以一并删掉。先切走，然后执行git branch -D 分支名即可。

这里需要特别提醒的是“跟踪关系”问题。当远程分支被删除后，本地分支依然会保留它原本的上游配置。如果你执行git push，Git 会因为找不到远程分支而报错，提示类似：

fatal: The current branch feat/old-login has no upstream branch.

这种情况下，要么重新设置上游分支，要么把本地分支也删掉。不同团队对这类“死分支”的处理策略不一样，我建议在团队内部定一个简单规则：远程分支删除后，本地分支在 3 天内完成清理或重新关联，避免每个人都留一堆无用的本地分支。

4. 以 refine 仓库为例的完整实操

4.1 refine 项目的分支结构复盘

下面用一个实际的例子来完整走一遍流程。这里以refine项目为例。refine是一个开源的 React 框架，主要用于快速构建内部工具、管理后台这类应用，它的仓库分支结构和大多数中大型开源项目差不多，分为主干分支、开发分支、功能分支和修复分支。

假设我们要清理的是feat/refine-login-redesign这个分支。它在远程已经合入了 PR，但本地和远程都还残留着。

先复盘一下当前状态：

• 远程仓库有一个feat/refine-login-redesign分支，已经合并进main
• 本地有一个同名的跟踪分支，长时间没有更新
• 远程还有几个历史遗留的旧分支，比如feat/old-dashboard、fix/typo
• 本地因为团队成员删除过几个远程分支，导致git branch -r里能看到一堆不存在的引用

这个场景非常典型，下面我们一步步来清理。

4.2 从状态检查到本地清理的完整命令流

第一步，进入项目目录，先看一眼整体状态：

cd refine git status git branch -vv

假设当前在main分支上，git branch -vv能看到本地分支列表，包括feat/refine-login-redesign以及它跟踪的远程分支。

第二步，确认要删除的本地分支是否已经合并：

git branch --merged main | grep 'refine-login-redesign'

如果这条命令输出了分支名，说明它已经合并进main，可以放心删除。如果没有输出，说明主干的提交历史里找不到这个分支的合并记录，需要进一步确认是否用了 Squash merge。refine 这类开源项目普遍使用 Squash merge，所以即使没被识别为已合并，只要确认 PR 已经合入，就可以考虑用-D。

第三步，安全删除本地分支：

git branch -d feat/refine-login-redesign

如果提示not fully merged，说明合并检查不通过。这时候回到上面提到的排查思路，确认 PR 状态后决定是否改用-D。

第四步，删除远程分支：

git push origin --delete feat/refine-login-redesign

第五步，清理所有远程残留引用：

git fetch --prune origin

第六步，再确认一遍最终状态：

git branch -vv git branch -r

到这一步，feat/refine-login-redesign这个分支就已经从本地和远程彻底清除了。

4.3 批量清理 refine 仓库遗留旧分支的实操记录

除了明确要删的分支，refine 仓库里可能还遗留着多个旧功能分支。这些分支往往是在不同时间段创建、在不同 PR 中合并的，清理方式类似，但需要额外注意批量操作的安全性。

我建议先列一个“清理清单”，把要删的分支名确认清楚。比如要清理feat/old-dashboard和fix/typo，先分别检查它们的合并状态：

git branch --merged main | grep 'old-dashboard' git branch --merged main | grep 'typo'

确认已合并后，可以批量删除本地分支：

git branch -d feat/old-dashboard fix/typo

然后批量删除远程分支：

git push origin --delete feat/old-dashboard fix/typo

注意，git push origin --delete支持同时传多个分支名，用空格分隔即可。执行后 Git 会分别输出每个分支的删除结果。

最后执行git fetch --prune origin清理本地残留引用。整套流程结束后，运行git branch -a检查，输出应该只有主干和确实仍在使用的分支。

5. 常见问题与避坑经验

5.1 分支删除后代码还能找回吗

这个问题被问过无数次，答案是：可以，但前提是你知道找谁。Git 的 reflog 记录的是本地仓库所有引用（HEAD、分支等）的变动历史，包括分支删除事件。

假设你刚删除了feat/refine-login-redesign分支，想找回它最后指向的提交，执行：

git reflog

输出里会看到类似这样的记录：

a1b2c3d HEAD@{0}: Branch: renamed refs/heads/feat/refine-login-redesign to refs/heads/feat/refine-login-redesign

或者你直接查看 reflog 里与分支相关的引用：

git reflog show feat/refine-login-redesign

不过分支删除后，这条引用通常不会单独保留，但 HEAD 的 reflog 会记录你“踩过这个分支”的痕迹。如果你在删除前切到过这个分支，那么它的最后提交哈希会出现在 HEAD reflog 里。

找到哈希后，可以基于它重建分支：

git checkout -b feat/refine-login-redesign a1b2c3d

这样代码就找回来了。

如果你的操作发生在远程仓库，比如远程分支被删，本地没有对应的 reflog，那就要看有没有其他同事的本地仓库里有这个分支的引用。团队协作场景下，只要还有一个人本地有这份代码，就能推回去。这也解释了为什么我一直强调：删除前确认合并状态，比删除后想办法找回要省事得多。

5.2 误删分支后的快速恢复方法

误删分支后的第一反应不是慌张，而是立刻停止一切可能“污染”仓库的操作。新开终端，切到项目目录，执行git reflog。

我举个例子。假设我误删了一个本地分支feat/magic-button，执行完git branch -D feat/magic-button后立刻发现不对。此时我输入git reflog，输出里会有最近的操作记录。找到Branch: renamed refs/heads/feat/magic-button to refs/heads/feat/magic-button之前的那条记录，通常前面就是分支的提交哈希。

如果找不到明确的记录，可以使用另一种思路：看当前 HEAD 指向的提交，然后用git fsck --lost-found查找所有“悬空提交”：

git fsck --lost-found

这个命令会扫描仓库对象数据库中不被任何引用指向的提交对象，误删的分支提交一般就藏在这里。输出会列出类似dangling commit a1b2c3d的内容，然后你结合提交时间和提交信息判断哪个是要找的，最后用git branch 分支名 哈希恢复。

需要说明的是，git fsck在大型仓库里输出可能很多，需要耐心筛选。另外，如果误删之后你又做了大量操作，比如大量提交或 GC，找回的难度会增加。所以第一时间操作，成功率最高。

5.3 不同 IDE 环境下分支清理的差异与坑

平时用命令行是基本功，但很多人日常都在 VS Code、IDEA 等 IDE 里操作 Git。IDE 的可视化按钮确实方便，但也有一些容易被坑的地方。

在 VS Code 里，源代码管理面板的分支图标可以切换分支，右键分支可以删除。但 VS Code 删除本地分支时，如果分支未合并，它会弹窗确认，不会像命令行一样直接报错拒绝。很多人没仔细看提示就点了确认，结果分支没了。所以在 VS Code 里删除分支时，一定要留意对话框里有没有 “Force Delete” 字样，如果有，说明这个分支有未合并提交，你要确认自己真的不需要这些代码。

IDEA 的分支管理界面同样支持删除本地和远程分支。删除远程分支时，IDEA 会调起git push --delete操作，所以不会有特殊问题。但 IDEA 里有个小坑：删除远程分支后，本地分支列表里可能还残留着原来的远程跟踪分支，需要手动执行git fetch --prune来清理。而在 IDEA 的 Git 工具窗口里，拉取按钮有一个下拉选项，里面包含了 “Prune Remote Branches” 的选项，勾选后再拉取就能自动清理。

如果你经常在 IDE 和命令行之间切换，建议保持两者的配置统一，尤其是把fetch.prune设为true。这样无论在哪个环境操作，远程分支清理行为都比较一致，不容易出现“IDE 里删了远程分支，命令行里还能看到一堆幽灵分支”的割裂感。

5.4 分支命名规范与删除策略的团队建议

分支清理不光是技术活，更是管理活。一个分支命名混乱的仓库，清理的时候光分辨“这个分支是干嘛的”就能耗掉大量时间。我建议团队内部约定一套简单的分支命名规范，比如：

• 功能分支：feat/简短描述，例如feat/refine-login-redesign
• 修复分支：fix/简短描述，例如fix/login-page-crash
• 发布分支：release/版本号，例如release/v1.2.0
• 实验分支：experiment/简短描述，例如experiment/refine-new-table

这套规范的核心价值在于：任何时候看到一个分支名，你都能大致判断它属于哪类工作、生命周期会有多长。功能分支和修复分支通常是短期存在的，合并后即可删除；发布分支则往往需要保留一段时间，直到对应版本稳定；实验分支用完即弃，甚至可以不推送到远程。

删除策略方面，我倾向于下面几条硬规则：

• 所有已合并的功能分支、修复分支，在 PR 合并后一周内删除
• 实验分支不推送远程，本地用完即删
• 远程分支删除后，拉取时自动执行 prune 清理本地引用
• 主干分支（main、develop）永远不删

定好规则之后，还需要有人定期检查执行情况。Git 本身没有“自动清理过期分支”的功能，所以完全依赖团队成员的自觉。如果你发现仓库里分支越来越乱，可以每隔一段时间做一次集中清理，方法就是前面讲的那些命令，把清单列出来，逐条确认，然后批量删除。

这套流程我在多个项目里跑过，效果不错，放在 refine 这类多人协作的开源仓库场景里尤其适用。分支清理虽然是小操作，但整理干净之后，仓库的可维护性会明显提升，团队成员也不会再被一堆不知道能不能删的分支搞得畏手畏脚。