我的代码库中的一些cherry-pick操作被记录为合并操作,这会影响git选择合并基准点。是否可以指定合并基准点?如果可以,怎样指定?
例如:f分支是从A提交的master分支创建的。C被cherry-pick到f分支,但被误导性地作为一个带有K和C父节点的合并提交。
当将f合并到主分支时,Git会找到C作为最佳的共同祖先,并将其用作基础。由于B包含在基础中,但在f中缺失,所以它将被合并撤销。使用A作为基础将给出正确的合并结果。
编辑:这个答案排除了下面提到的B计划。因此,希望有人能回答:如何在Git合并中指定合并基础?
编辑,B计划:该存储库通过使用TFS-Git从两个具有挑选工作流程的TFS分支获取而变得如此。一个变更集的“合并选定范围”显示为完全合并。另一种解决方案是以某种方式配置git-tfs,以不创建合并提交。(停止所有挑选不是一个选项。)
例如:f分支是从A提交的master分支创建的。C被cherry-pick到f分支,但被误导性地作为一个带有K和C父节点的合并提交。
A-B-C master
\ \
K---C'-L f
当将f合并到主分支时,Git会找到C作为最佳的共同祖先,并将其用作基础。由于B包含在基础中,但在f中缺失,所以它将被合并撤销。使用A作为基础将给出正确的合并结果。
编辑:这个答案排除了下面提到的B计划。因此,希望有人能回答:如何在Git合并中指定合并基础?
编辑,B计划:该存储库通过使用TFS-Git从两个具有挑选工作流程的TFS分支获取而变得如此。一个变更集的“合并选定范围”显示为完全合并。另一种解决方案是以某种方式配置git-tfs,以不创建合并提交。(停止所有挑选不是一个选项。)
C
而不是B
,那么是不是意味着从进一步的工作中可以得出B
?如果不是,那么在您的示例中,B
是否也应该被选择或者仅仅继续在C
上进行? - Florian Neumann