推送到远程时包含压缩提交的原始提交？

Question

问题

确保远程具有针对PR的压缩提交内的提交有什么好方法？

背景

我正在使用Github，并在推送到原点之前将我的提交压缩为单个功能提交。

如果我只推动压扁的提交，Github（也就是遥控器上的git blob）似乎并不知道单个预压缩提交（Github-markdown通常会将[<commitSHA>]转换为链接到提交，但这不会发生）

我猜我可以推动我的未分支分支，然后从原点删除它。然后压扁我的提交，并重新推动。但这似乎有点容易出错。

理想情况下，有一个git push参数可以检查reflog以了解哪些提交进入了一个压缩的提交并包含它们。这将是很好的。

注意也可以对此工作流程的合理性发表评论

Answer 1

对github没有太多经验，但以下工作流程与您的问题相关。

• 为您的工作创建新分支
• 将此分支推送到远程而不用压缩
• 当功能准备就绪时，结帐主分支，执行merge feature_branch --squash并推送它。

因此，主分支具有单个提交和整体工作，但其父级之一是具有所有开发历史的分支。所有提交都在远程表示，因此链接应该可以正常工作。

Answer 2

一对夫妇注意到：

1）在正常的工作流程中，“压缩”提交的行为意味着您说“这些单独的提交并不重要;我将它们创建为我的开发工作流程的一部分，但在记录的历史记录中，我希望它们被理解为单个提交”。通过参考个人提交，你正在反对自己。

2）尽管（1），你可以保留原始提交。但是，git不会将它们理解为与压缩的提交，或您的分支或任何后续工作相关。主机功能（如Github的提交链接）可能确实有效，但如果代码的状态非常重要，值得这样的链接，那么我质疑从分支历史中删除它的智慧。

3）考虑到（1）和（2），另一种方法是使用真正的合并而不是压缩合并。这将使工具的默认行为按预期工作，您无需采取特殊步骤即可在origin上识别您的个人提交。当然，您认为您不希望这样做，因为它将各个提交保留在默认的log输出中。但是，这就是log命令具有--first-parent参数的原因。

4）如果你认为你只需要使用壁球合并并在单独的引用下推送原始提交，它就会起作用。但与您的问题中的推测相反，它是不然后安全删除您用来推送它们的引用。如果这样做，最终可能会通过垃圾回收删除单个提交。

5）另一方面，与nnovich-Ok的回答似乎暗示相反，你不必在挤压之前推动，因为挤压不是一种破坏行为。

因此，如果你真的想要，你可以保留各个提交的功能分支，同时使用南瓜来维护简化的master历史记录，理解git不会识别所有这些分支之间的关系;你不能删除功能分支，因为它们只是让个人提交保持活着;并且你正在用困难的方式解决问题，用未使用的分支混乱你的ref列表，所有这些都是为git命令集内置的东西。