在审核评论后，从Web界面上的拉取请求中压缩GitHub提交记录？

Question

假设我有5个提交的提交历史记录。我知道可以在创建拉取请求时本地重新安排我的提交，然后将它们重定位到单个提交中。

这种情况的常见用例包括：

- 进行本地提交，处理功能 - 合并提交 - 创建拉取请求 - 接收审查评论 - 适当更新拉取请求

我可以在本地执行此操作，然后再次推送我的更改（使用-f，因为rebase使其与远程不同步）。这有点麻烦。

但是，这要求每次处理评论时都进行rebase - 是否有任何方法可以从Web界面执行此操作？

或者，我的工作流程可能有误，我应该直接将每个“审查评论”提交修改到主要PR提交中吗？

- enderland

Answer 1

您不再需要在本地进行任何rebase/squash操作：只需将您的提交推送到PR分支即可。

如果原始仓库的所有者选择这样做（自2016年3月以来），他/她将为您合并这些提交：

请参阅“压缩您的提交”和文档：它确实为您作为贡献者和原始存储库的维护者提供了一种新的工作流。

就像下面我所评论的那样：它将像PR的合并一样实现：

• 如果没有冲突，合并（或这里的merge --squash：请参见“在git中，merge --squash和rebase之间有什么区别？”）将自动创建。
• 如果有任何冲突，合并将不会创建，并且维护者可以选择暂时拒绝PR，并要求贡献者执行squash提交和修改PR的工作。

这与现有情况非常相似，只是GitHub在其合并命令中添加了--squash。没有更多的变化。

- VonC

---

我们昨天在工作中谈论了这个 - 这一定不是愚人节的恶作剧吧？ :) 我很好奇它将如何工作，因为如果它基本上是变基，那么它将需要所有中间提交才能成功自动变基（而不需要手动合并）。如果它只是采用“最终状态”与“初始状态”并进行差异比较？那就太好了。 - enderland

@enderland 这并不是愚人节玩笑！GitHub可能在倾听 https://github.com/dear-github/dear-github 的声音。 - VonC

@enderland，在实践中它将表现良好，因为它只会在主分支上生成一个提交。 - VonC

我知道这是最终结果。但是它将如何实现？它是自动执行git rebase --squash master吗？还是进行更复杂的补丁或差异处理？其中一些比其他工作效果更好。如果自动化无法正常工作，那么是否会导致“无法挤压，合并冲突”的情况？ - enderland

@enderland 它将像实现 PR 合并一样实现。如果它没有冲突，合并（或这里的 merge --squash：https://dev59.com/VnE95IYBdhLWcg3wKqyq#2427520）将自动创建。如果有任何冲突，合并不会被创建，维护者有选择拒绝 PR，要求贡献者做压缩提交和修改 PR 的工作。这与现有情况非常相似，只是 GitHub 在其合并命令中添加了 --squash。没有更多的东西。 - VonC