git - 显示已经 "squashed & merged"进入master的本地分支

Question

在我们团队的存储库中，我们通过提交 PR 来工作，我们只使用 github 的压缩和 merge 功能将它们 merge 到 master 中。对我来说，问题是我再也看不到使用 git branch --merged merge 到 master 中的分支，因为这不会显示已压缩和 merge 的分支。我本地的分支机构堆积如山，要逐一审查它们以查看我可以删除哪些是一件痛苦的事情。是否有其他方式列出它们？

Answer 1

tl;dr; 很遗憾，没有。你必须在 GitHub 上检查你的 PR 的状态，一旦它被 merge ，用 git branch -D 强行删除你的本地分支。 .

《压缩与 merge 》图解

GitHub Squash and merge操作实际上并没有 merge 你的 topic branch ― 相反，它将来自该分支的所有提交压缩为一个，然后 rebase 在目标分支之上提交。

来自documentation :

When you select the Squash and merge option on a pull request on GitHub, the pull request's commits are squashed into a single commit.

最重要的部分:

Pull requests with squashed commits are merged using the fast-forward option.

A fast-forward merge不会创建 merge 提交——它只是将目标分支引用向前移动，以便它指向与源分支相同的提交。仅当源分支指向作为目标分支的后代的提交时，才能完成此操作。

因此，如果您的主题分支在您的本地存储库中看起来像这样:

         master
         v
o--o--o--o
    \
     A--B--C  <- This is the branch you want to merge with a PR
           ^
           topic

当您使用 Squash and merge 时，GitHub 将重写您的topic 分支的历史，使其看起来像这样:

         master
         v
o--o--o--o
    \
     S  <- This is A, B and C squashed together
     ^
     topic

然后，GitHub 将在 master 之上 rebase topic。请注意，由于父级不同，这将导致与原始压缩提交 S 不同的提交；为了区分它，我们称重基提交为S'(S prime):

         master
         v
o--o--o--o
          \
           S'
           ^
           topic

最后，topic 分支被 merge 到 master 中，带有 fast-forward merge :

            master
            v
o--o--o--o--S'
            ^
            topic

这一切都发生在托管在 GitHub 服务器上的存储库中。与此同时，在你的机器上，存储库仍然是这样的:

         master
         v
o--o--o--o
    \
     A--B--C
           ^
           topic

完成后 git pull在 master 上，您将收到压缩和 rebase 的提交 S':

            master
            v
o--o--o--o--S'
    \
     A--B--C
           ^
           topic

Git 无法知道提交 S' 包含来自 A、B 和 C 的组合更改>。这就是为什么它仍会将 topic 报告为 unmerged。

实际考虑

Linus Torvalds 曾经 wrote :

People can (and probably should) rebase their private trees (their own work). That's a cleanup. But never other peoples code. That's a "destroy history".

然后他继续说:

You must never EVER destroy other peoples history. You must not rebase commits other people did. Basically, if it doesn't have your sign-off on it, it's off limits: you can't rebase it, because it's not yours.

GitHub的Squash and merge应该很明显功能通过完全重写他们的 PR 分支来破坏其他人的历史。

我不会坐在这里告诉你Squash and merge本质上是邪恶的——我相信它有它的用途。

但是，如果您的团队经常发现自己不得不处理过时的本地分支(如您所描述的)，您可能需要考虑切换到 merge 工作流，该工作流按原样 而不是摧毁它。