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

Question

我收到了公关，并希望压缩这些提交，所以这很好。

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

注意：此问题与me squashing my own commits无关。

这是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会引用）但是你会在文字提交作者身上失去个性。

  

所以我不能压缩蓝色提交（一个）然后红色提交（一个）？ PR中有两个吗？

是的，你可以完全这样做，并且压缩应该是你在拉动请求中建议的东西，这样你只能为每一个提交一个提交。如果你将所有蓝色提交压缩成一个并将所有红色提交压缩为一个，你就可以实现我想要的，即在保持作者历史的同时清理你的git日志。

  

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

不确定。您可以以交互方式重新绑定以将多个提交压缩在一起。当你在蓝色提交的任何一方进行红色提交时，你的问题就会出现，这会限制你的壁球能力。

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

我模拟了一些虚拟提交作为例子：

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

在你的控制台中，为列表中的第一个蓝色提交（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

当变基完成后，你的蓝色提交将全部压缩在一起：

$ 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日志现在会告诉你，你有一个被压扁的蓝色提交。

切换回你的主分支并再次进行rebase，这次跳过Blue提交并将红色提交压缩在一起：

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

Git log现在将向您显示您只有一个Red commit。现在你再次cherry-pick蓝色的那个回来了：

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

如果这些提交都触摸相同的文件，您将遇到问题。在这种情况下，您可能只需要保持红色在蓝色周围的分离。

重要

我强烈建议你建议你的Github项目的所有贡献者在拉取请求过程中将所有提交压缩成一个，然后你就不必自己处理这些问题了。

HTH。