【问题标题】:find the "rebase -m" starting point找到“rebase -m”起点
【发布时间】:2017-11-16 09:21:06
【问题描述】:

最近在用

git checkout dev_branch -b merge_branch
git rebase -m merge_branch master
git checkout master
git rebase merge_branch

做一个合并变基。如帮助文档所示,merge_branch 首先重置为 master 的 HEAD,然后将原始 dev_branch 中的新提交一一回放到新分支。

几天后,我想找到这个 rebase 合并的“起点”在哪里。我可以使用

在 dev_branch 中找到第一个增量提交
git merge-base master dev_branch // Get an SHA_root of the common ancestor
git log --reverse -1 <SHA_root>..dev_branch  // Get an SHA_delta of the first delta commit

但我找不到找到合并版本的方法

git branch --contains <SHA_delta>

但是发现它只在“dev_branch”中,而不在“master_branch”中,虽然实际上它已经被合并了。

换句话说,具有不同父级的相同提交(例如使用cherry-pick的情况)具有不同的SHA。有没有办法 git 可以识别它们实际上是相同的?

【问题讨论】:

    标签: git merge rebase cherry-pick


    【解决方案1】:

    这就是git cherry 所做的。

    如果topic 包含三个提交,并且维护者应用了其中两个,情况可能如下所示:

    $ git log --graph --oneline --decorate --boundary origin/master...topic
    * 7654321 (origin/master) upstream tip commit
    [... snip some other commits ...]
    * cccc111 cherry-pick of C
    * aaaa111 cherry-pick of A
    

    [……剪掉更多发生的事情……]

    | * cccc000 (topic) commit C
    | * bbbb000 commit B
    | * aaaa000 commit A
    |/
    * 1234567 branch point
    

    在这种情况下,git cherry 会简要说明尚未应用的内容:

    $ git cherry origin/master topic
    - cccc000... commit C
    + bbbb000... commit B
    - aaaa000... commit A
    

    在这里,我们看到提交 A 和 C(标有 -)可以从您的 topic 分支中删除,当您在 origin/master 之上重新设置它时,提交 B(标有 + ) 仍然需要保留,以便将其发送到origin/master

    【讨论】:

    • Greg,感谢您介绍这个有用的命令。但看起来它不处理合并涉及一些手动更改(用于解决冲突)或文件被删除的情况。
    猜你喜欢
    • 1970-01-01
    • 2016-12-05
    • 1970-01-01
    • 1970-01-01
    • 2016-02-19
    • 1970-01-01
    • 2017-08-25
    • 1970-01-01
    • 1970-01-01
    相关资源
    最近更新 更多