压缩打开的拉取请求的变更集是否可以？

Question

我在以下情况中：

1. 我向dev分支提交了一些补丁
2. 我在stash或github或bitbucket推送分支
3. 我打开从dev到master的合并请求
4. 我推出了一些修补审核者报告问题的新补丁

事实证明，为了提高清晰度和一致性，一些补丁可以用以前的补丁压扁。

可以这样做（然后强制推送到远程开发分支）？在某些情况下，这可能会破坏合并请求体验中的某些内容吗？

修改

感谢您的回答。

我实际上是项目存储库的所有者，而不是创建合并请求的实际用户。我完全理解git的合并和重新定位机制，所以不需要解释git的内部。

问题更多：作为审稿人，您是否会要求提交者在有意义的情况下压缩其中的一些补丁？根据您的经验，它是否会禁用或破坏提供拉取请求的某些机会。

Answer 1

一旦推送提交，重写历史记录（实际上创建新历史记录）将导致问题。在推送更改后，您的存储库看起来像这样。

A - B - C - D - E - F [origin/master] [master]
             \
              1 - 2 - 3 - 4 - 5 - 6 - 7 - 8 [dev] [origin/dev]

假设您认为6可以被压扁为3，而7可以被压扁为4.你做了一次改变并结束了这个......

A - B - C - D - E - F [origin/master] [master]
             \
              1 - 2 - 3 - 4 - 5 - 6 - 7 - 8 [origin/dev]
                   \
                    3b - 4b - 5b - 8b [dev]

即使5和8没有直接改变，但必须重写它们，因为他们的父母改变了，他们最终得到了新的ID。您的开发分支与远程分支发生了分歧。如果你推动你必须强迫它并吹掉3,4,5,6,7和8.这会给其他人带来麻烦。

任何拔出你的开发分支的人现在都会在尝试推或拉时出错。他们必须pull --force进行更新。如果他们在你的分支机构上完成了工作，那就太复杂了。

任何引用提交3 - 8（评论，评论，日志条目等等）的内容现在都指向错误的地方。

但是，它应该合并得很好。

一些拉取请求系统比其他系统更好地处理这个问题。最后我看，Github会将您的重新提交作为新提交呈现，它可能会让人感到有些困惑。因此，我建议您询问项目是否要他们清理您的分支机构或者保持原样。

Answer 2

1. 审稿人通常希望根据他们的反馈来查看您提交的提交之间的细微差异。如果你压缩提交，那么他们可能会感到困惑，因为他们现在必须审查许多更改。

2. 另一方面，如果你不压缩提交，有时你可能需要将你的分支重新建立在其他分支上。而且由于你没有压缩提交，你可能会看到每次提交的合并冲突都很痛苦。

Answer 3

不，绝对不是 ¹ 。

只要您推动更改供其他人审核，您就已发布了历史记录。并且很少想要编辑已发布的历史记录。你应该只压制和改变自己没有与任何人共享的个人提交。

我能理解表现出清洁，完美和＃34;历史。将原始历史推向世界并且在任何提交中都没有错误，这将是一件好事。但为时已晚！你犯了一些错误，其他一些开发人员发现了它们。因此，您希望通过重写历史来隐藏您的错误。在这个世界上，你的历史可以是干净的，也可以是准确的，但它不能同时存在。

是的，重写历史记录非常诱人因为您对此感到尴尬。

如果你不压扁，

• 审稿人可以在历史记录中准确了解您是如何解决他们的问题的。

• 如果有人提出与其他代码相似的问题，那么以后可以使用历史作为参考。历史是学习代码的宝贵工具！

• 审核人员不必从头开始审核您的整个拉取请求，因为他们已经审核过早期版本。

• 你值得信赖！你没有隐瞒事情。

• 如果某人已经开始审核您的更改，那么他们下次就不会遇到问题。

如果你做壁球，

• 你会觉得自己是一个完美的开发者，并没有犯过错误。多么自负！

没有挤压已发布的历史记录！

¹ ：在某些情况下，如果您对格式化/空白或意外提交的构建产品进行了一些意外更改，或者首先应该从事历史记录的事情，请继续并重写历史记录（所以你不要打破git blame）。所以不要接受“＃34;绝对＆＃34;面子。