标签 git
<分区>
在我们的项目中，我们使用 GIT 作为 SCM。像往常一样，我们为新功能、复杂的错误修复、下一个版本等创建单独的分支。当(例如)一个新特性被完全实现时，它们被 merge 到 master 中，这是我们的“下一个版本”分支(并被 merge 到主干中，并在以后的测试/部署期间生效)。所以在一个新的功能分支被 merge 到 master 之后，它就“死了”。目前我删除了“死”分支以保持分支列表小而清晰。但正如我在最后一次删除时注意到的那样，我这样做是以丢失分支历史记录为代价的。
我现在的问题是:处理“死”分支的最佳方法是什么？
最佳答案
我会说已经 merge 到master的分支，即由
列出git branch --merged
可以而且应该安全地删除
git branch -d <merged_branch>
git push --delete origin <merged_branch>
Git 的优点之一是创建(和 merge )分支非常容易。您应该“尽早且经常分支”。但是让所有那些旧的已删除分支随处可见是很麻烦的。重要的历史信息存在于提交及其彼此之间的关系中。
请记住， merge 提交的自动生成消息包含分支的名称。所以确定原始分支名称通常没有问题(以防它包含一些有趣的信息)。
没有 merge 的分支另当别论:
git branch --no-merged
不能用-d删除，必须用-D删除，不易误操作。就个人而言，我最终也删除了那些，但我等待的时间很多。
关于git - 在 GIT 中处理 "dead/unused"分支的最佳方法是什么？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/17173297/
相关文章：
git - 在 Visual Studio Team Explorer 中切换源代码管理上下文
r - 如何从 R 获取当前 git commit 的 sha
git annex 无法与 dropbox 建立 SSL 连接
git - 为什么 "git flow feature pull"不跟踪？
git - 我可以让 git add -p 显示像 git diff --word-diff 这样的更改吗？
linux - 从 GIT 存储库中提取时如何确保 Linux 文件所有权正确
git - 如何推送浅更新？在远程设置 receive.shallowUpdate？