我正在尝试使用交互式rebase来更改拉取请求的电子邮件。它出现在git log
中commit 0b7e8dc4ebe9fb6ee4394cbf6effb3d43b8cd6a8
Merge: 9de954e 30a5ede
Author: test user <testuser@gmail.com>
Date: Sun Feb 11 08:29:41 2018 +0100
Merge pull request #1 from tester/greenkeep/initial
所以我知道它就在那里,但是当我尝试做一次改变时,我看不到它。
我看到其他所有提交。有什么特例吗?
拉取请求在github上。
我知道不建议重写历史记录,我已经在使用拉取请求之前完成了这个,它似乎丢失了吗?
令人困惑的是git rebase -i
甚至没有显示拉取请求消息。我甚至试过
git rebase -i head~20
我知道拉请求已经完成了几次提交。
有什么想法吗?
答案 0 :(得分:2)
Rebase discards 合并,如the linked question。
拉取请求本质上是向其他人发送消息,要求他们将您的提交合并或重新绑定到他们的工作中,因此要回答的第一个问题是您是否需要< em>您自己的在这一系列提交中合并。 如果他们选择重新提交您的一系列提交,他们的 rebase将会丢弃您的合并。(如果他们选择非在GitHub上合并“squash”选项。你可以在不使用GitHub的情况下以老派的方式进行拉取请求,但是因为你用github标记了这个,我会假设你也使用GitHub做了拉取请求。)
如果他们要合并,那么您的合并将包含在他们合并您的提交时添加到其存储库的一系列提交中。在这种情况下,您可能希望使用新的更正合并提交(使用正确的作者)替换现有的合并提交(使用其不正确的作者)。如果它不是你提交的一系列提示,那可能会相当困难。在这种情况下,请查看Rebasing a Git merge commit的答案,并注意let subject = pm["subject"]
实际上重新执行合并。
您也可以考虑使用git rebase --preserve-merges
更改一次提交,如Change the author and committer name and e-mail of multiple commits in Git,但使用git filter-branch
变量来测试一个特定的提交哈希ID。请注意,filter-branch很难正确使用;始终在存储库的副本上进行实验。
如果合并提交正好在提交的提示中,那么您要求其他人提取,但有一种更简单的方法:只使用$GIT_COMMIT
。 git commit --amend --reset-author
代码知道如何将合并提交复制到修改的合并提交,并且由于在合并提交之后没有提交,因此没有后续提交需要复制 - 使用新的“修改”提交的新哈希ID更改操作。
(--amend
和interactive-rebase代码在部分中比较复杂,因为一旦你在一系列提交的中间复制但调整了提交,每个 >后续的提交也必须进行复制 - 调整,以使用其替换父级的新哈希ID。使用filter-branch
时,没有后续提交,所以这并发症简直消失了。)