我可以在提交的PR中压缩_other peoples_ git提交吗？

Question

我收到了公关,并希望压缩提交,所以这很好.

我不确定我是否可以这样做或各自的作者必须这样做？当然,我希望保留作者的名字引用他们的壁球提交.

注意:这个问题不是关于我压缩自己的提交.

这是PR在Git中的样子:

或通过cli:

c:\Projects\Foo>git log --pretty=oneline
7fab9ae1031c13414909668f342582bdc8081f5a <Author - Red>
a02270b2014fd3995456773cd7badc7df0c72cf6 <Author - Blue>
6ae3d6c8b5a8b037c0e4dc88d24ec5598ff1933e <Author - Blue>
100f6513aacbe431b56f3082597749cddca284c8 <Author - Blue>
d263a5c8924053678f455b5ee8515bbb16aacf49 <Author - Blue>
c3cc5dbc13ac77e0a552a2d3132d255df3c7a6e4 <Author - Blue>
71f89b3f3dd583cd97d4a0806a973a4d1af64fe9 <Author - Red>
f14ef616a852f3a7311f4f7b9e05d460e0574422 <Author - Red>
015f30b3828828404b5549ee8a7df2aefdfa9424 <Author - Red>
9b22a4d2ded54cb754883d9d6418a39eb34df7cf <Author - Red>
33a10e9828d04cf82439a6c60b8cf4c0c2f122a3 <Author - Red>
4615c7747c4546809b29e063986c697c7c64cbc4 Added Specific naming rules, section.
b8ee154e38338022649caef40945c6f0297a59ce Added method parameters, section.
bc860c7609cc80caf41fc5944c1b39201019a80e Added Input and View Models, section.
ad6b3e4bee1cb9d8afcf9cd1fa8815769d80133b Fixed bad markdown formatting.
5929d5b38aad8bb7cc3da4976dd81883eab0f999 Added more testing info.
18b64dfc3769766ac2bb841e6346b555d00751f1 Create README.md
d7761e57a5bbd7de587b766c83d2a3134c0bc58b Added xUnit and Shouldly NuGet packages.
7f2ea8cdd97958d347df8079ef2eebb6b7f1647c We need unit tests....
ee31bbfe0572e0e49872edcf1a6fc2c426ed0d15 :money_with_wings: We are alive!

那里有消息的提交,那些是我的,而不是这个PR的一部分.

有什么我可以做的吗？或者我还需要其他作者吗？

Answer 1

评论最终变成了答案，所以我将在这里总结一下：

我不确定我是否可以做到，或者相应的作者必须这样做？当然，我希望保留作者的名字引用他们的壁球提交。

如果你压缩任何提交，你最终只会得到一个提交，并且一个提交只能有一个作者。它们可能仍会在提交消息中被引用（默认情况下 Git 会这样做），但您将失去文字提交作者的个性。

那么我不能将蓝色提交（合二为一）然后将红色提交（合二为一）压缩吗？所以公关里有两个？

是的，您完全可以这样做，并且压缩应该是您在拉取请求中建议的内容，以便您只为每个提交进行一次提交。如果您将所有蓝色提交压缩为一个，并将所有红色提交压缩为一个，您就实现了我认为您想要的，即清理您的 git 日志，同时仍保持作者历史记录。

伟大的！.. 任何建议如何做到这一点？

当然。您可以交互式地变基以将多个提交压缩在一起。当您在蓝色提交的任一侧进行红色提交时，您的问题就会出现，这会限制您的壁球能力。

对于蓝色提交，您可以在执行 a 时将它们压缩到列表中的第一个提交中git rebase -i HEAD~11（在最后 11 个提交中加载以进行交互式变基）。

我模拟了一些虚拟提交用作示例：

$ git log --oneline
7e8be9c Red
b740f97 Blue
325b375 Blue
553d733 Red
bb5599b Red

在您的控制台中，为列表中的第一个 Blue 提交 (bd63d63) 选择“p”或“pick”，为所有其他提交选择“f”或“fixup”以丢弃其提交消息，或“s”或“壁球”，如果你想为他们保留提交信息：

$ git rebase -i HEAD~5
pick bb5599b Red
pick 553d733 Red
pick 325b375 Blue
fixup b740f97 Blue
pick 7e8be9c Red

当 rebase 完成后，你的蓝色提交将被压缩在一起：

$ git log --oneline
a341d97 Red
488c19e Blue
553d733 Red
bb5599b Red

这可能会变得复杂，具体取决于 Red 和 Blue 是否接触过相同的文件。

如果他们还没有那么你最好的办法是cherry-pick将蓝色提交到一个单独的分支（没有红色或蓝色）或重新设置它，重新设置原始并压缩红色提交，同时丢弃蓝色提交，然后将临时分支合并回来在，例如：

$ git checkout -b tempbranch
$ git reset --hard XXXXXXX # this is the commit BEFORE any red or blues
$ git cherry-pick 488c19e

Git log 现在会告诉你你有一个被压扁的 Blue 提交。

切换回你的主分支并再次变基，这次跳过蓝色提交并将红色提交压缩在一起：

$ git rebase -i HEAD~4
pick bb5599b Red
fixup 553d733 Red
drop 488c19e Blue
fixup a341d97 Red

Git 日志现在将显示您只有一个红色提交。现在你cherry-pick又回来了：

$ git cherry-pick 488c19e
$ git log --oneline
fc96b04 Blue
0280ef9 Red

如果这些提交都涉及相同的文件，您就会遇到问题。在这种情况下，您可能只需要将红色与蓝色分开。

重要的

我强烈建议你建议你的 Github 项目的所有贡献者将他们所有的提交压缩成一个作为拉取请求过程的一部分，这样你就不必自己处理这些问题了。

哈。