合并分支后找到功能分支的源分支提交？
考虑一个包含主分支和发布分支的 git 工作流。Master 继续前进到下一个版本。Bug 修复将应用于发布分支，但必须向后移植到主分支。
功能分支在发布分支上创建、审阅并合并到发布分支中。功能分支现在必须重新定位到主分支，才能将修补程序也应用于主分支。然而
git rebase --onto master release
导致 0 次提交。这是有道理的，因为发布已经向前推进，并且
git merge-base HEAD release
结果为 HEAD（内部使用合并基来确定变基起点）。因此，变基会导致不重定基数。没用。
我可以使用 git log 来确定我认为分支点可能在哪里，但我真的很想知道分支点最有可能在哪里。目标是针对这种常见情况实现更好的自动化。
一个简单的示例树（树很少这么简单。 :)：
* 5caf21e (release) Merge pull request #689 from ...
|
| * 9f0f210 Bug 1123: Fix bug
| * bb6b3fa Bug 1123: Reproduce bug
* 077afe0 Merge pull request #688 from ...
|
| * e750974 (feature/bug1154) Bug 1154: Fix bug
| * 98194b9 Bug 1154: Reproduce bug
* cabb4d2 Merge pull request #681 ...
|
| * a10c992 Bug 1110: Bug fix
| /
* 7caacee Merge pull request #673 ...
我想将 e750974 处的功能/bug1154 变基到主分支。此分支已合并，发布分支也已移动。
git rebase --onto master release feature/bug1154
导致不应用任何提交。
我真的很想做
git rebase --onto master cabb4d2 feature/bug1154
如何使用 git 命令找到 cabb4d2？可以自动化并轻松向其他人解释的东西，而无需手动解释 git 日志。
我不完全了解情况（请参阅我的评论），但我会尝试一下。
如何向后移植功能？
向后移植一两个提交的常用命令是 git cherry-pick 。但根据您的工作流程，我认为这不是您想要的。
错误修复应用于发布分支，但必须向后移植到主分支
如果主分支是为未来版本所做的工作，而发布分支是维护/错误修复，那么这只是一个合并。如果人们应该在发布时合并每个错误以掌握它们，那么修复错误 1123 的人可能已经合并了 1154。
合并分支后，如何找到功能分支的源分支提交？
从技术上讲，Git 不会在任何地方记录这一点，甚至在分支合并之前也是如此。命令git merge-base --fork-point可以推断出它，但前提是本地 reflog 有足够的历史记录。
如何使用 git 命令找到 cabb4d2？
如果您知道合并点是 077afe0，则git merge-base 077afe0^1 077afe0^2
退一步说，从您的问题中不清楚功能/bug1154 有什么特别之处。无论 1110 和 1123 有什么流程，这都是 1154 应该做的。如果 master 指向 5caf23e 的后代，那么它已经被合并了。