似乎已经有一些类似的问题，但没有一个是我想要的。
假设我有这样的提交历史记录
* xxxxxxxH (HEAD -> B) Latest commit
* (more commits)
* xxxxxxxG (B) More commits
* xxxxxxxF Merge branch 'master' into B
|
| * xxxxxxxE (master) Another commit on master
| * (more commits here)
| * xxxxxxxD Commit on master
* | xxxxxxxC Another commit
* | (more commits here)
* | xxxxxxxB First commit on branch A
|/
* xxxxxxxA (master) some commit
现在我想重写分支 A 的历史记录，可能会合并或编辑一些提交，但我也想更改分支 A 上的第一次提交，并且我还想保留合并，以便我保持 master 合并到 A 中。
我首先直观地尝试了git rebase -i -p xxxxxxxB，但显然这不包括 xxxxxxB 提交本身。因此，git rebase -i -p xxxxxxxB^了另一个尝试，它确实包括了该提交，但现在它实际上并没有保留合并。
另一个看起来很有前途的选项是--root，但这个选项从整个存储库中的第一次提交开始，这也不是我想要的。
有什么方法可以做我想做的事吗？
经过比我认为合理的时间更长的时间，我能够在 irc 上得到一个解决方案：
git rebase -i -m -r firstCommitInBranch^完全符合我的需求。
来自 git 文档：
-r, --rebase-merges[=(rebase-cousins|no-rebase-cousins)]
By default, a rebase will simply drop merge commits from the todo list, and put
the rebased commits into a single, linear branch. With --rebase-merges, the
rebase will instead try to preserve the branching structure within the commits
that are to be rebased, by recreating the merge commits. Any resolved merge
conflicts or manual amendments in these merge commits will have to be
resolved/re-applied manually.
(...)
The --rebase-merges mode is similar in spirit to --preserve-merges, but in
contrast to that option works well in interactive rebases: commits can be
reordered, inserted and dropped at will.
和
-m, --merge
Use merging strategies to rebase. When the recursive (default) merge strategy is
used, this allows rebase to be aware of renames on the upstream side.
我也错过了文档中说不要将-p与-i一起使用的部分：
-p, --preserve-merges
Recreate merge commits instead of flattening the history by replaying commits a
merge commit introduces. Merge conflict resolutions or manual amendments to merge
commits are not preserved.
This uses the --interactive machinery internally, but combining it with the
--interactive option explicitly is generally not a good idea unless you know what
you are doing (see BUGS below).