1.1 案例研究：使用git branch -d安全删除已合并分支

我经常在完成功能开发后遇到本地分支堆积的情况。当某个分支的代码已经成功合并到主分支（比如main或master），使用git branch -d 分支名是最稳妥的清理方式。这个命令就像Git的安全卫士，会先检查目标分支是否完全合并到当前所在分支，确认无误后才执行删除操作。

假设我最近开发了一个支付功能分支feature-payment，将其合并到main分支后，运行git branch -d feature-payment。Git此时会比对分支历史，如果发现这个分支的所有提交都已包含在main分支里，就会安静地删除这个分支。这种机制有效避免了误删含有未合并代码的分支，特别适合团队协作时保持代码库整洁。

有时会遇到Git拒绝删除的情况，提示"not fully merged"。这种情况通常意味着我可能漏掉了某些提交的合并，或者存在尚未推送的本地提交。这时候需要重新检查分支合并状态，用git log main..feature-payment查看差异，确认是否需要保留某些修改。如果确定要删除，才会考虑更暴力的-D参数。

1.2 案例研究：git branch -D强制删除未合并的本地分支

当我在临时分支做技术验证时，经常会产生不想保留的测试代码。比如创建了experiment-ui分支尝试新的界面方案，但最终决定放弃这个方向。这时候git branch -D 分支名就派上用场了，这个命令像把锋利的手术刀，可以立即切除未合并的分支，哪怕它包含重要的代码变更。

上周我在hotfix-login分支调试登录模块问题时，突然接到通知说这个问题已经被其他同事解决。这时运行git branch -D hotfix-login就能立即清除这个冗余分支，避免分支列表出现混乱。需要注意的是这个操作会永久删除分支及其所有未合并提交，就像清空回收站前没有二次确认，因此执行前建议用git log 分支名确认没有需要保留的代码。

对比-d和-D的使用场景，我发现前者适合日常维护，后者则是紧急清理工具。在持续集成环境中，经常需要批量清理过期的功能分支，这时编写脚本结合git branch -D可以显著提升效率，不过要特别注意做好备份或代码审查，防止误删重要工作成果。

2.1 案例研究：恢复误删的本地分支（结合reflog与commit哈希）

误删分支就像不小心清空了未保存的文档，这种惊心动魄的瞬间我经历过不止一次。有次重构用户模块时，不小心用git branch -D user-redesign删除了尚未合并的分支，当时心跳都漏了一拍。好在Git的reflog功能就像时间机器，能找回最近30天的操作记录。立即运行git reflog --date=local，在密密麻麻的操作日志里寻找带有"commit: 用户模块重构"描述的那条记录，对应的哈希值就是分支最后存在的节点。

找到目标哈希值后，用git checkout -b user-redesign 哈希值前七位就能让分支起死回生。这个操作相当于在历史时间线上重新建立分支指针，整个过程不过十秒，但后背已经出了一层冷汗。恢复后我立刻用git diff main对比确认所有修改都完整存在，那种失而复得的感觉就像找回了手机里珍贵的照片。

2.2 案例研究：同步删除远程分支（git push origin --delete与本地清理联动）

本地分支清理干净后，远程仓库里可能还挂着同名的"僵尸分支"，这种情况在团队协作中经常遇到。上周我们合并了feature-analytics数据分析模块，虽然本地用git branch -d删除了分支，但远程仓库的对应分支依然存在，导致新同事误以为这个功能还在开发中。

这时候git push origin --delete feature-analytics就像远程遥控器，能精准清除云端的分支。执行命令后立即刷新Git仓库页面，看到那个灰色的分支名消失时特别有成就感。不过本地还会保留着origin/feature-analytics这个远程跟踪分支的缓存，需要用git fetch --prune给本地仓库做个"深层清洁"，这样运行git branch -a时才不会看到已经消失的幽灵分支。

有个容易忽略的细节是，当多人协作时可能有其他同事还在使用这个远程分支。有次我刚删完远程分支，就收到同事询问为什么他git pull后出现提示。后来我们约定删除远程分支前要在群里同步通知，就像收拾公共区域时要提前喊一声"我要关灯了"那样，避免给团队协作带来意外困扰。