当我编写代码时，我将其分解为易于查看的简单逻辑更改。
为此，我使用git rebase -i（交互式）来压缩，删除和更改提交顺序。
我注意到这有时会导致GitHub拉取请求的提交顺序不同（尽管订单保留在远程分支上）。
例如，
可能会出现在公关中：
我搜索了互联网，只设法找到这个GitHub帮助页面：Why are my commits in the wrong order?他们的回答：
如果您通过git rebase或强制推送重写提交历史记录，您可能会注意到打开拉取请求时您的提交顺序无序。
GitHub强调Pull Requests是一个讨论的空间。它的所有方面 - 注释，引用和提交 - 都按时间顺序表示。重写你的Git提交历史记录while performing rebases改变了时空连续体，这意味着提交可能没有像你期望的那样在GitHub接口中表示。
如果您总是希望按顺序查看提交，我们建议您不要使用
git rebase。但是，请放心，当你看到时间顺序以外的东西时，什么都不会破坏！
有办法解决这个问题吗？
我已成功解决了这个问题：
git rebase -i <hash of that commit>pick替换所有rewordgit push -f在此之前，我尝试仅更改第一个提交消息，该消息也会更改以下所有哈希值，但这并未修复它。
我必须为之后的每一次提交都这样做才能使它工作。
如何修复GitHub拉取请求中的提交顺序，由git rebase打破？
这可以通过（仍在讨论）2019 git evolve command完成：
目的
创建“
evolve”命令以帮助用户制作高质量的提交历史记录。用户可以按任意顺序一次改进提交，然后运行
git evolve重写其最近的历史记录，以确保一切都是最新的。 我们会在更改图表中跟踪对提交的修订。用户可以使用标准的push，fetch和format-patch命令交换更改图，从而与他人分享他们的进度。状态
该提案尚未实施。
背景
想象一下，您有三个连续的更改需要审核，并且您收到需要编辑所有三个更改的反馈。 我们稍后会正式定义“更改”这个词，但是暂时让我们说改变是一个正在进行的工作，其最终版本将在未来作为提交提交。
当您编辑一个更改时，会有更多反馈到达其他更改。 你是做什么？
evolve命令是处理正在审查的提交链的便捷方式。 每当您重新定义或修改提交时，存储库都会记住旧提交已过时并已被新提交替换。然后，在将来的某个时刻，您可以运行“
git evolve”，并且正确的rebase序列将以正确的顺序发生，这样任何提交都不会有过时的父级。使“
evolve”命令工作的一部分涉及随着时间的推移跟踪对提交的编辑，这就是我们需要更改图的原因。 但是，更改图表还将带来其他好处：
- 用户可以直接查看更改的历史记录（它经历的修改和重组的顺序，与它所在的分支的历史正交）。
- 可以快速定位并列出用户当前正在进行的所有更改。
- 它可以用作组合或拆分更改的其他高级命令的一部分。
- 它可用于装饰提交（在
git log，gitk等中），这些提交要么已过时，要么是正在进行的工作的提示。- 通过推送和提取更改图表，用户可以更轻松地协作处理正在进行的更改。 这比推送和拉动更改更好，因为更改图可用于定位更具体的合并基础，从而允许在同一更改的不同版本之间进行更好的合并。
- 在运行
git-filter-branch之后，它可以用于正确地修改本地更改和其他本地分支。- 它可以取代gerrit使用的
change-id页脚。
我建议像这样的~/.gitconfig别名：
[alias]
rewrite = rebase -x 'git commit --amend -C HEAD --date=\"$(date -R)\" && sleep 1.05'
在完成常规的rebase -i master修复之后，你可以简单地做一个git rewrite master来修复GitHub提交命令。它将基于旧的每秒创建一个新的提交。通过覆盖--date，它将迫使GitHub保持正确的顺序。
rebase的--ignore-date选项可用于重置提交的作者日期。这将修复github上的提交顺序。
使用强制推送，您甚至可以在现有的拉取请求上修复提交顺序。
例如：
git checkout my_pull_request_branchgit rebase --ignore-date origin/mastergit push -f origin my_pull_request_branch