gitbranch -r --no-merged 列出已经合并的分支

Question

我们将 kickstart 代码保存在 git 存储库中，以便它在所有 kickstart 服务器上保持一致。我们有一个小脚本来显示所有当前分支，询问您要使用哪一个，然后将其拉下来并确保代码可供所有人阅读。部分代码：

git checkout main >/dev/null 2>&1
git fetch --all >/dev/null 2>&1
git pull >/dev/null 2>&1
git branch -r --no-merged
echo "  main"

它不是只列出未合并的分支，而是列出了我们曾经拥有的几乎每个分支。我做错了什么？

Answer 1

它不是只列出未合并的分支，而是列出了我们曾经拥有的几乎每个分支。

这很可能发生，因为 Git 实际上并不合并分支，而是合并提交。选取您认为不应该存在的任何分支，然后尝试以下命令：

git log main..<some-branch-name>

这将向您显示该分支“上”但不在“上”的所有提交

main

。如果该命令的输出为空，则根据定义该分支已完全合并。

大多数分支可能“不合并”的一些原因是：

合并分支时，会使用一种策略来重写合并的提交。流行工具中的一些常见合并策略称为：挤压合并、变基合并或半线性合并以及变基快进。如果使用了任何这些策略，并且原始功能分支没有被重写也没有被删除，那么它们都会以未合并的状态存在。
在过去的某个时刻，您的
```
main
```
分支被重写，但功能分支没有被重写。
功能分支合并后，更多提交被添加到这些功能分支中，可能是由于分支名称的重用。
如果工作流程是这样的，用户碰巧在最后决定最后一个分支之前推送了许多正在进行的工作分支，那么您可能只有一堆旧的正在进行的工作分支，开发人员从来没有费心去清理。

您可以轻松证明 #1 是否是罪魁祸首：当您运行上面的命令时，搜索列出的提交，看看它们是否也存在于

main

中，但具有不同的提交 ID。如果提交消息、作者和日期相同，但它们具有不同的提交日期和提交 ID，那么这指向 rebase 合并或 rebase 快进策略，该策略在进行合并之前也不会重写功能分支。