我最初在分支oldstable上，我想将master的所有提交都反向移植到它

A---B---C oldstable <- HEAD
         /
    D---E---F---G master

我想要的：

A---B---C---F’---G’ oldstable <- HEAD
         /
    D---E---F---G master

我确实读过git rebase的文档，但没有太大的成功。理想情况下，我会喜欢像git rebase --into-this-branch master或git rebase oldstable..master oldstable这样的东西，其中master中的提交，而不是当前分支（oldstable）中的提交，将被重基到它里面。
我找到了几种方法来做到这一点，但如果我把它们放在脚本中，它们都不是很符合人体工程学。

git switch --detach master   # or `git checkout --detach master` if you prefer
git rebase oldstable
git branch --force oldstable # manually move the commit pointed by oldstable
git switch oldstable         # or `git checkout topic` if you prefer

这里的问题是，如果rebase需要手动干预（例如，存在合并冲突），那么当rebase完成时，我将不再在oldstable上，或者如果我用git rebase --abort中止它。
我也试过：

git cherry-pick $(git log --reverse --pretty="%H" oldstable..master)

这个方法的问题是，如果合并冲突，git status对于理解哪些提交被选中，哪些提交失败，还有什么需要做（比如使用git rebase时）没有任何用处，它也不会自动忽略已经被选中到oldstable的提交。
我试过了

# we assume that there all modifications are commited or stashed
current_commit="$(git rev-parse oldstable)"
git reset --hard master
git rebase ${current_commit}

主要问题是git rebase --abort将使oldstable指向与master相同的提交，而不是将其重置为C。
编辑：

• 为什么不合并？

因为真实的的用例是只将一些在master中但还没有在oldstable中的提交进行backport。一个更精确但更复杂的例子是将H和I转换为oldstable，这只是git rebase --onto oldstable master~2 master的变体，但我想移动oldstable而不是master。

A---B---C oldstable <- HEAD
         /
    D---E---F---G---H---I master

• 您是否正在寻找git cherry-pick F G？

这正是git cherry-pick $(git log --reverse --pretty="%H" oldstable..master)所做的（更多细节见上文）。

• 你为什么关心你是否在变基后登陆oldstable？

简短的回答。因为git rebase将被隐藏到脚本中。我可以在执行rebase之前分离HEAD，如第一次尝试所示，但我不想在rebase冲突时使repo处于混乱状态。如果我是该脚本的唯一用户，这根本不是问题。但我的想法是让我经验不足的git同事也可以使用这个脚本，我认为他们可能会在完成后忘记执行git switch -C oldstable，并被repo的状态搞糊涂。
很长的答案。我所做的是我只想将一些来自master的提交反向移植到oldstable。我具体做的是将来自master的提交转换为oldstable，除了要排除的提交列表。该提交列表存储在文本文件中。从该列表中，我生成了一个子脚本，它将从提交列表中过滤它们然后，我设置$EDITOR，使其在交互式变基期间指向该子脚本（env EDITOR=that/sub/script.sh git rebase --interactive oldstable master）。整个过程被 Package 到我或我的同事将使用的backport.sh脚本中。这工作得很好，除了在rebase期间移动了错误的分支/oldstable没有移动/上面提到的其他问题。