压缩的拉取请求是否作为单个提交显示在贡献图中？

Question

我正在开发功能分支，在一两周内可以有一百多个提交。我预计一旦我的拉取请求被接受，这些每日提交就会在我的贡献图上获得每日标记，但是当该拉取请求被“压缩并合并”时，它看起来只是在贡献图上显示为单个提交。

这是预期的行为，还是我的提交因其他原因而丢失？

Answer 1

是的，这是预期的行为。您只合并了一项提交。这就是挤压和合并的要点。

我不建议挤压合并。它需要所有仔细考虑的有关分支开发方式的提交历史记录，并将其混合成方便但均匀的糊状物。

我正在开发功能分支，在一两周内可以有一百多个提交。

我想说这才是真正的问题。功能分支不应经常有超过一百个提交。您的功能太大，或者您进行了大量提交来修复以前的提交，或者您因更新分支而进行了大量偶然合并提交，或者以上所有情况。

使用rebase而不是更新您的分支merge。git rebase main重写您的分支，就好像它一直是在最新版本的 main 之上编写的一样。这会删除只显示“我更新了我的分支”的合并提交，并且可以更轻松地查看分支上已完成的工作。您可以通过设置默认情况下更改git pull为进行变基而不是合并。请参阅Git分支 - 变基。git pull --rebasepull.rebasegit-config

将大功能分解为一系列较小的功能。这是一项超出本答案范围的技能，但通常一个大的改变可以分解为一系列较小的重构。

消除偶然的修复提交。如果您需要修复上一个提交中的某些内容，请不要使用git commit --amend.

对于一般清理，请进行交互式变基并单独压缩您的偶然提交。使用fixup。

$ git rebase -i master

pick abcd1234 feature: do that thing
fixup 1234dcba whoops, had a typo in that thing
fixup b33fdead docs: document that thing
fixup afdcefff test: test that thing
fixup deadb33f fix that thing
pick efga1389 feature: did another thing

你有六次提交，但你只做了两件事。现在，您只需两次提交即可完成两件事。

使用这些技术，您可以将 PR 简化为一些经过深思熟虑的提交，每个提交都向审阅者和未来的开发人员传达重要信息，他们想知道为什么要这样编写代码。

有关更多信息，请参阅重写历史。

Answer 2

是的，它们显示为单个提交。这是因为 GitHub 只计算最终在默认分支上的提交，当您压缩 PR 时，您最终会在默认分支上得到一次提交。

我个人并不担心我的贡献图，所以这对我来说并不重要。但是，我也不使用压缩和合并，因为我编写了漂亮的、可平分的提交，并具有良好的提交消息，而压缩和合并会破坏它。如果不将贡献者所做的工作减少到单个提交对您来说很重要，那么您将需要一个合并策略，其目标不是明确破坏历史记录。