git – 找出我们试图挑选的提交的依赖关系

2023年3月26日 195次阅读

假设如下：

                            HEAD/master     
                             |
A<--B<--C<--D<--E<--F<--G<--J  
        ^
        official

官员是分支机构.
我想向官方分支机构挑选2个提交,例如E和J.
这两个提交都是影响相同3个文件的修复程序.
当我做了git cherry-pick E它很好但是当我做了git cherry-pick J时我遇到了一些冲突.
看看差异,我意识到我还需要提取提交F,它对这3个文件中的两个进行了更改,这些更改基本上是方法定义更改而J是在此之上完成的.
所以只需要做一下git cherry-pick F&& amp; git cherry-pick J
题：
如果我不知道在这些文件中完成的更改并且提交F是一个很大的提交更改了许多文件：是否有另一种方法来确定我们尝试提取的提交依赖于没有手动执行git日志的提交在文件上并通过提交进行提交？

最佳答案

Is there another way to figure out on which commit a commit we are trying to cherry pick depends on without manually doing a git log on the file and going commit by commit?

是的 – 我写了git-deps来自动完成这项任务.因为它目前接受一系列要提交的提交,所以在你的例子中,你需要传递一个包含提交J的单一范围,并告诉它排除任何已经正式的依赖：

git deps --exclude-commits official J^!

在幕后,工具将使用J查看J ^的差异,然后对任何被删除或修改的行以及周围上下文的可配置行数运行git blame.这将导致它发现J中删除或修改的一行或多行来自提交F,因此它将输出提交F的SHA1.

git-deps不仅可以发现单个提交或提交范围的依赖关系,还可以递归整个依赖关系树.因此,您描述的整个樱桃采摘场景可以自动化为一个命令：

git deps --recurse --exclude-commits official J^! | \ 
    tsort | \ 
    tac | \ 
    xargs -t git cherry-pick

请注意,这只能保证所有樱桃选择都干净利落,而不是它们在语义上是正确的.因此,仍然需要仔细检查所得的分支头并测试其正确性.

更方便地在分支之间移植提交是git-deps最明显(但不是唯一)的用例,因此我有dedicated a section of the README specifically to this use case.它甚至包括一个YouTube视频,向您展示如何使用它.

如果您想了解更多详情,可能会对我在此以及其他相关工具上提出的几个演讲感兴趣：

> a talk given to the Git London User Group
> a talk given at an OpenStack developer conference

我还谈到了这个工具
episode #32 of the GitMinutes podcast.

点赞