Question

如何在合并分支后找到功能分支的源分支提交？

考虑具有主分支和发布分支的git工作流。大师继续前进到下一个版本。错误修复应用于发布分支，但必须后端移植到主分支。

功能分支在发布分支上创建，审阅并合并到发布分支中。现在必须将功能分支重新定位到主分支以将修复应用于主分支。然而，

git rebase --onto master release

结果为0次提交。这有意义，因为发布已经向前发展并且

git merge-base HEAD release

导致HEAD（内部使用merge-base来确定rebase起点）。因此，rebase导致什么都不变。没用。

我可以使用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日志。

Answer 1

我不完全理解这种情况（请参阅我的评论），但我会采取措施。

如何备份功能？

传递一两个提交的常用命令是git cherry-pick。但根据您的工作流程，我不认为这是您想要的。

错误修复应用于发布分支，但必须后端移植到主分支

如果主分支是为将来的版本完成的工作而发布分支是维护/错误修复，那么这只是一个合并。如果人们应该在发布时将每个bug合并到master中，那么修复bug 1123的人可能已经合并了1154.

如何在合并分支后找到功能分支的源分支提交？

从技术上讲，即使在合并分支之前，Git也无法在任何地方录制。命令git merge-base --fork-point可以推断出它，但前提是本地reflog有足够的历史记录。

如何使用git命令找到cabb4d2？

如果您知道合并点是077afe0，那么git merge-base 077afe0^1 077afe0^2

退一步说，你的问题并不清楚feature / bug1154的特殊之处。无论1110和1123的流程是什么，都应该为1154做什么。如果master指向5caf23e的后代，那么它已经被合并了。

合并后如何备份功能分支？

1 个答案: