Question

我正在编写一个代码，我发现自己的情况类似于this blog上解释的情况。基本上，我有两个版本的代码，使用完全不同的容器。这样做是为了比较使用不同容器时代码的效率。因为我依赖于高效的容器成员函数，所以我不能使代码在容器方面具有通用性，所以我选择了一种方法，我有两个git分支：一个用于优化代码，另一个用于未优化的代码。

问题在于，在优化了部分代码之后，我需要在两个分支上进行一些常用工作。是否可以在“上游”（非优化）分支上进行工作，然后在不解决大量冲突的情况下挑选优化分支的常见提交？

我已经按照在线发现的教程，创建了一个带有单个文件的虚拟存储库（用于测试冲突）和一些分支。

对于this git repository example，是否有可能在没有解决冲突的情况下选择在分支“second”上提交“02秒”进入主分支？我没有反对解决冲突的问题，但如果可以避免，我感兴趣。

在这种情况下，正确的工作流程是什么？我应该应用常见的变更，提交，挑选和解决冲突，就是这样吗？

Answer 1

提交是补丁集

Cherry-picking不会本身引入冲突。很多与你的提交的原子性有关。将提交视为应用于树的一组补丁。如果你的补丁没有重叠，那么你可以挑剔而不受惩罚。另一方面，如果你有广泛的，重叠的或复杂的提交，那么一个樱桃选择通常会包含比平滑应用更多的更改。

考虑一下：

# Patch A
Line one
Line two
Line three

# Patch B
Line one
Line 2
Line three

# Current HEAD
First line
Second line
Third line

有了这个人为的例子（注意：我没有测试它，我只是用它来说明一点），试图将A和B两者一起挑选到HEAD可能不会干净利落，因为这些变化重叠。另一方面，樱桃采摘如下：

# Cherry-pick me from another branch!
First line
Second line
Third line
Fourth line

到HEAD将不会引入冲突，因为没有重叠。

显然，具体的用例可能有所不同，但一般的经验法则是，小型的原子提交已经成熟，可以采摘樱桃，而“大泥球”提交通常是有问题的。 YMMV。

樱桃选择提交时，冲突是否是不可避免的？

1 个答案:

提交是补丁集

另请参阅