如何修复 GitHub 拉取请求中被 git rebase 破坏的提交顺序？
How to fix commit order in GitHub pull requests, broken by git rebase?
当我编写代码时，我将其分解成小的逻辑更改，以便于快速审查。
为此，我使用 git rebase -i（交互式）来压缩、删除和更改提交的顺序。
我注意到这有时会导致 GitHub 拉取请求的提交顺序不同（尽管该顺序保留在远程分支上）。
例如，
- 提交 1
- 提交 2
- 提交 3
可能会在 PR 中显示为：
- 提交 3
- 提交 1
- 提交 2
我搜索了互联网，只找到了这个 GitHub 帮助页面：Why are my commits in the wrong order? 他们的回答：
If you rewrite your commit history via git rebase or a force push, you
may notice that your commit sequence is out of order when opening a
pull request.
GitHub emphasizes Pull Requests as a space for discussion. All aspects
of it--comments, references, and commits--are represented in a
chronological order. Rewriting your Git commit history while
performing rebases alters the space-time continuum, which means
that commits may not be represented the way you expect them to in the
GitHub interface.
If you always want to see commits in order, we recommend not using
git rebase. However, rest assured that nothing is broken when you
see things outside of a chronological order!
有办法解决这个问题吗？
我已经通过以下方式解决了这个问题：
- 找到保留顺序的最后一次提交
- 运行
git rebase -i <hash of that commit>
- 将所有
pick替换为reword
- 运行
git push -f
在此之前，我尝试只更改第一个提交消息，这也更改了以下所有哈希值，但并没有解决它。
我也必须为每个后续提交都这样做才能工作。
自动化 suggested I use a script from Piotr:
git rebase "$(git merge-base HEAD master)" --ignore-date -x 'git commit --amend -C HEAD --date="$(date -R)" && sleep 1.05'
rebase 的 --ignore-date 选项可用于重置提交的作者日期。这将修复 github.
上的提交顺序
通过强制推送，您甚至可以修复现有拉取请求的提交顺序。
例如：
git checkout my_pull_request_branchgit rebase --ignore-date origin/mastergit push -f origin my_pull_request_branch
How to fix commit order in GitHub pull requests, broken by git rebase?
这可以在（仍在讨论中）2019 git evolve command:
Objective
Create an "evolve" command to help users craft a high quality commit history.
Users can improve commits one at a time and in any order, then run git evolve to
rewrite their recent history to ensure everything is up-to-date.
We track amendments to a commit over time in a change graph. Users can share their
progress with others by exchanging their change graphs using the standard push,
fetch, and format-patch commands.
Status
This proposal has not been implemented yet.
Background
Imagine you have three sequential changes up for review and you receive feedback
that requires editing all three changes.
We'll define the word "change" formally later, but for the moment let's say that a change is a work-in-progress whose final version will be submitted as a commit in the future.
While you're editing one change, more feedback arrives on one of the others.
What do you do?
The evolve command is a convenient way to work with chains of commits that are
under review.
Whenever you rebase or amend a commit, the repository remembers that the old commit is obsolete and has been replaced by the new one.
Then, at some point in the future, you can run "git evolve" and the correct sequence of rebases will occur in the correct order such that no commit has an obsolete
parent.
Part of making the "evolve" command work involves tracking the edits to a commit
over time, which is why we need an change graph.
However, the change graph will also bring other benefits:
- Users can view the history of a change directly (the sequence of amends and
rebases it has undergone, orthogonal to the history of the branch it is on).
- It will be possible to quickly locate and list all the changes the user
currently has in progress.
- It can be used as part of other high-level commands that combine or split
changes.
- It can be used to decorate commits (in
git log, gitk, etc) that are either
obsolete or are the tip of a work in progress.
- By pushing and pulling the change graph, users can collaborate more
easily on changes-in-progress.
This is better than pushing and pulling the
changes themselves since the change graph can be used to locate a more
specific merge base, allowing for better merges between different versions of
the same change.
- It could be used to correctly rebase local changes and other local branches
after running
git-filter-branch.
- It can replace the
change-id footer used by gerrit.
我建议使用这样的 ~/.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 保持正确的顺序。
您可能不再需要修复任何东西（2020 年 7 月，3 年后）
参见：
Pull request commits now ordered chronologically
We are changing the way commits are ordered in the pull request timeline and commits view.
Commits are currently ordered by author date, which can cause commits to appear out of order in some scenarios, like after rebasing.
With this change, commits are ordered according to their chronological order in the head branch, which is consistent with the ordering in Git.
This ordering is also reflected in the List commits on a pull request REST API and PullRequest object's timeline connection in GraphQL.
Learn more about pull requests
当我编写代码时，我将其分解成小的逻辑更改，以便于快速审查。
为此，我使用 git rebase -i（交互式）来压缩、删除和更改提交的顺序。
我注意到这有时会导致 GitHub 拉取请求的提交顺序不同（尽管该顺序保留在远程分支上）。
例如，
- 提交 1
- 提交 2
- 提交 3
可能会在 PR 中显示为：
- 提交 3
- 提交 1
- 提交 2
我搜索了互联网，只找到了这个 GitHub 帮助页面：Why are my commits in the wrong order? 他们的回答：
If you rewrite your commit history via git rebase or a force push, you may notice that your commit sequence is out of order when opening a pull request.
GitHub emphasizes Pull Requests as a space for discussion. All aspects of it--comments, references, and commits--are represented in a chronological order. Rewriting your Git commit history while performing rebases alters the space-time continuum, which means that commits may not be represented the way you expect them to in the GitHub interface.
If you always want to see commits in order, we recommend not using
git rebase. However, rest assured that nothing is broken when you see things outside of a chronological order!
有办法解决这个问题吗？
我已经通过以下方式解决了这个问题：
- 找到保留顺序的最后一次提交
- 运行
git rebase -i <hash of that commit> - 将所有
pick替换为reword - 运行
git push -f
在此之前，我尝试只更改第一个提交消息，这也更改了以下所有哈希值，但并没有解决它。
我也必须为每个后续提交都这样做才能工作。
自动化
git rebase "$(git merge-base HEAD master)" --ignore-date -x 'git commit --amend -C HEAD --date="$(date -R)" && sleep 1.05'
rebase 的 --ignore-date 选项可用于重置提交的作者日期。这将修复 github.
通过强制推送，您甚至可以修复现有拉取请求的提交顺序。
例如：
git checkout my_pull_request_branchgit rebase --ignore-date origin/mastergit push -f origin my_pull_request_branch
How to fix commit order in GitHub pull requests, broken by git rebase?
这可以在（仍在讨论中）2019 git evolve command:
Objective
Create an "
evolve" command to help users craft a high quality commit history.Users can improve commits one at a time and in any order, then run
git evolveto rewrite their recent history to ensure everything is up-to-date.
We track amendments to a commit over time in a change graph. Users can share their progress with others by exchanging their change graphs using the standard push, fetch, and format-patch commands.Status
This proposal has not been implemented yet.
Background
Imagine you have three sequential changes up for review and you receive feedback that requires editing all three changes.
We'll define the word "change" formally later, but for the moment let's say that a change is a work-in-progress whose final version will be submitted as a commit in the future.While you're editing one change, more feedback arrives on one of the others.
What do you do?The
evolvecommand is a convenient way to work with chains of commits that are under review.
Whenever you rebase or amend a commit, the repository remembers that the old commit is obsolete and has been replaced by the new one.Then, at some point in the future, you can run "
git evolve" and the correct sequence of rebases will occur in the correct order such that no commit has an obsolete parent.Part of making the "
evolve" command work involves tracking the edits to a commit over time, which is why we need an change graph.
However, the change graph will also bring other benefits:
- Users can view the history of a change directly (the sequence of amends and rebases it has undergone, orthogonal to the history of the branch it is on).
- It will be possible to quickly locate and list all the changes the user currently has in progress.
- It can be used as part of other high-level commands that combine or split changes.
- It can be used to decorate commits (in
git log,gitk, etc) that are either obsolete or are the tip of a work in progress.- By pushing and pulling the change graph, users can collaborate more easily on changes-in-progress.
This is better than pushing and pulling the changes themselves since the change graph can be used to locate a more specific merge base, allowing for better merges between different versions of the same change.- It could be used to correctly rebase local changes and other local branches after running
git-filter-branch.- It can replace the
change-idfooter used by gerrit.
我建议使用这样的 ~/.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 保持正确的顺序。
您可能不再需要修复任何东西（2020 年 7 月，3 年后）
参见：
Pull request commits now ordered chronologically
We are changing the way commits are ordered in the pull request timeline and commits view.
Commits are currently ordered by author date, which can cause commits to appear out of order in some scenarios, like after rebasing.
With this change, commits are ordered according to their chronological order in the head branch, which is consistent with the ordering in Git.
This ordering is also reflected in the List commits on a pull request REST API and
PullRequestobject's timeline connection in GraphQL.Learn more about pull requests