&quot“重新派遣”基于另一个的git特征分支
我希望有人知道解决分支混乱所需的 git-fu。
我有一个功能分支 - FB2 - 其父级是 FB1,而 FB1 又源自 master。
坏消息:我需要在 master 之上重新定位 FB2,因为它需要在 FB1 之前发布,而不需要 FB1 的任何提交。
好消息:FB2 中几乎没有直接与 FB1 变更集交互的代码更改。然而,来自 FB1 和 FB2 的许多票证 (~75) 的拉取请求有数十个提交。
我正在寻找最不痛苦的方法来查找并合并直接提交给 FB2 的提交。或者,可以更改现有 FB2 分支以重新定位 master 并删除源自 FB1 的所有提交。
强力挑选或重新定位将花费很长时间并且容易出错。
“git rebase --onto master FB1”在测试中似乎不起作用。 FB1 中的更改仍然存在于 FB2 中。
谢谢!
类似于这里的图:
# CURRENT
A--B--C--D // master
\
E--F--G // FB1
\
H--I--J // FB2
# DESIRED
H--I--J // FB2
/ \
A--B--C--D M // merged
\
E--F--G // FB1
I am hoping someone knows the git-fu required to untangle a branch mess.
I have a feature branch - FB2 - whose parent is FB1, which in turn originated from master.
Bad news: I need to retarget FB2 on top of master as it needs to ship before FB1, without any of the commits from FB1.
Good news: There are few code changes in FB2 that directly interact with changesets from FB1. However, there are dozens and dozens of commits from pull requests over many tickets (~75) from both FB1 and FB2.
I'm looking for the least painful way to find and incorporate only the commits which were committed directly to FB2. Alternatively, a way to alter the existing FB2 branch to retarget master and remove all the commits that originated from FB1.
brute force cherry picking or rebasing will take forever and be error prone.
"git rebase --onto master FB1" didn't seem to work in a test. The changes from FB1 were still present in FB2.
Thanks!
Similar to the diagram here:
# CURRENT
A--B--C--D // master
\
E--F--G // FB1
\
H--I--J // FB2
# DESIRED
H--I--J // FB2
/ \
A--B--C--D M // merged
\
E--F--G // FB1
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(1)
FB1 和 FB2 之间有过重新合并吗?或者你只是fb1和fb2的分支然后有自己的历史?如果是这样:
您可以尝试在提交 G 和 J 之间创建补丁:
然后在您实际想要开始的位置创建一个新分支并应用补丁:
但是,如果新目标分支上不存在文件,则补丁填充不适用干净地。
为此,您可能首先要做的是:
确定实际文件发生了哪些更改。
Have you had any re-merges between FB1 and FB2 ? Or you just branched of fb1 and fb2 then had its own history? if so :
you may try creating the patch between commits G and J:
then create a new branch where you actually want to start from and apply the patch:
However, if files do not exist on the new target branch, the patch fill not apply cleanly.
for that you may first want to do :
to identify what actual files changed.