何时取消基和压缩提交

此页描述何时对拉请求进行重基处理以及何时合并/压缩提交。

何时删除或合并/压缩提交

拉动请求 must 如果非源代码文件（例如图像、数据文件和，等等）被添加，然后在PR commit history中删除或修改（压缩应该删除除了最后添加的文件以外的所有文件，以避免在存储库中使用额外的空间）。

合并/压缩提交是 鼓励 当所做更改的提交数过多时。“过度”的定义是主观的，但一般来说，应该尝试将单个提交作为变更的单位，而不包括撤销。作为一个具体的例子，对于一个影响不到10行源代码并包含一个changelog条目的更改，提交次数过多将是过度的。但是，对于添加重要功能的更大的请求，更多的提交可能是合适的。

另一个指导原则是，压缩应该删除无关的信息，但不应该用来删除关于如何开发公关的有用信息。例如，应该压缩4个正在测试更改且提交消息仅为“debug”的提交。但是一系列的提交消息是“实现的featurex”、“added test for feature X”、“fixed bugs by tests for feature X”都是有用的信息，不应该无缘无故地压缩掉。

在压缩时，应特别注意为给定的PR提供实质性贡献的所有个人的署名信用，例如，只有同一作者所做的压缩承诺。

在任何情况下，都要注意保持一个友好的环境，并提供有益的建议，特别是对新的贡献者。E、 g.一个维护者应该主动帮助一个git新手用户的贡献者完成维护者要求的任何压缩，或者直接向PR分支推送来完成压缩。

何时回基

拉动请求 must 如果至少满足以下一个条件，则重新设置基址（但不一定压缩为单个提交）：

• 与师父有冲突

• 在PR commit history中有来自上游/主服务器的merge提交（从PR到用户fork的merge提交很好）

• 存在包含攻击性语言或违反行为准则的提交消息（在这种情况下，rebase还必须编辑提交消息）

Github“压缩和合并”按钮

我们不应该使用或启用GitHub的“压缩和合并”按钮，因为这会在处理识别后台端口时产生问题。