我习惯做很多小事。我的问题是它创造了一个健谈的历史，当我打开或更新拉取请求时，我想首先压缩它们。 然而，我（可能是错误的）理解是，一旦提交被推，压缩它 - 通过交互式rebase--更难。有没有好办法解决这个问题？
我应该提到所有的工作都是在私人分支机构完成的，从未被其他任何人检查过，直到拉取请求被关闭并且它被合并到我们的主分支中时才会看到。
答案 0 :(得分：2)
您的理解部分正确。您确实希望避免重新发布已发布的提交。然而，原因并不是它比重新发布未发布的提交更困难，而仅仅因为它给其他用户带来了麻烦。这是因为rebasing将导致这些提交被抛弃并被新提交所取代，新提交是不同且不兼容的对象。因此，那些已经知道那些原始提交的人在遇到那些取代旧提交的新提交时会遇到问题。
话虽这么说，当你正在为拉取请求工作时，你经常在一个单独的分支上工作。通常创建的分支，其唯一目的是将其作为拉取请求提交。因此，其他人已经在拉取请求的上下文之外使用它的机会相当小。因此，当您重新定位时，可能不会遇到问题（或让其他人遇到问题）。
许多项目实际上甚至要求您在将更改合并到存储库之前压缩更改。有时，您提交拉取请求，人们发表评论，导致您推送响应这些评论的新提交，使历史更加混乱。然后，当每个人都感到高兴并且变化准备合并时，通常会将这些更改重新设置为新的，新的提交，这些提交不会反映到达到那里的过程，而只是在干净和语义上显示最终结果分开的方式。
是的，您可以并且可能应该在提交拉取请求之前压缩您的更改。为此，只需使用master以交互方式将它们与基础分支（例如git rebase -i master）进行重新绑定，并使用重新排序和压缩功能来清理所有内容。我个人也喜欢使用git reset --soft master丢弃所有提交（我在使用之前创建备份分支）。 --soft导致所有文件更改保持原样，但将提交历史记录重置为master上的位置。因此，如果您要创建一个git commit，那么您将创建一个包含所有这些更改的提交。当然，您也可以使用git reset重置索引，然后有选择地添加更改以提交多个较小的提交，如果这看起来更合适。
当你完成后，使用git push --force强行将它们推送到你的远程分支，以覆盖旧的“凌乱”历史。如果您已经为分支打开了拉取请求，GitHub甚至会识别自动更新拉取请求，添加一条注释，替换了那里的提交。