Git Cherry-pick 与 merge 工作流

Question

假设我是一个 repo 的维护者，我想从贡献者那里获取更改，有几个可能的工作流程:

1. 我cherry-pick 从远程(按顺序)每次提交。在这种情况下，git 将提交记录为与远程分支无关。
2. 我 merge 分支， pull 入所有更改，并添加一个新的“冲突”提交(如果需要)。
3. 我 merge 分别(再次按顺序)从远程分支提交每个提交，允许为每个提交记录冲突，而不是将所有内容组合在一起。
4. 为了完整起见，您可以执行 rebase(与 cherry-pick 选项相同？)，但我的理解是这可能会给贡献者带来困惑。也许这消除了选项 1。

在情况 2 和情况 3 中，git 记录了提交的分支历史，这与情况 1 不同。

使用所描述的cherry-pick 或merge 方法之间的优缺点是什么？我的理解是方法 2 是常态，但我觉得用单个“冲突” merge 解决大型提交并不是最干净的解决方案。

Answer 1

rebase(和cherry-pick)和merge 都有各自的优点和缺点。我在这里主张 merge，但两者都值得理解。 (在此处查看替代的、争论不休的 answer 列举了首选 rebase 的情况。)

merge 优于 cherry-pick 和 rebase 有几个原因。

1. 稳健性。提交的 SHA1 标识符不仅可以识别它本身，还可以相对于在它之前的所有其他提交。这为您提供了保证，即给定 SHA1 的存储库状态在所有克隆中都是相同的。 (理论上)不可能有人做了看起来相同的更改，但实际上正在破坏或劫持您的存储库。您可以挑选个别更改，它们可能是相同的，但您不能保证。 (作为一个次要的次要问题，如果其他人再次在同一提交中挑选新的挑选提交将占用额外的空间，因为即使您的工作副本最终相同，它们也会出现在历史记录中。)
2. 易于使用。人们往往很容易理解 merge 工作流程。 rebase 往往被认为更高级。最好了解两者，但是不想成为版本控制专家的人(根据我的经验，这包括许多非常擅长他们所做的事情但不想花费额外时间的同事)有一个更容易的时间刚刚 merge 。

即使 merge 繁重的工作流 rebase 和 cherry-pick 仍然对特定情况有用:

1. merge 的一个缺点是历史困惑。 rebase 防止一长串提交分散在您的历史记录中，就像您定期 merge 其他人的更改一样。这实际上是我使用它的主要目的。您要非常注意的是，永远不要 rebase 您与其他存储库共享的代码。一旦一个提交被pushed，其他人可能已经在它上面提交了，rebase 充其量只会导致上面讨论的那种重复。在最坏的情况下，您最终可能会得到一个非常困惑的存储库和细微的错误，您需要很长时间才能找出这些错误。
2. cherry-pick 可用于从您基本上决定丢弃的主题分支中抽取一小部分更改，但意识到其中有几个有用的部分。

至于更喜欢 merge 许多更改而不是一个更改:它只是简单得多。一旦开始拥有大量变更集， merge 单个变更集会变得非常乏味。 git(以及 Mercurial 和 Bazaar)中的 merge 解决方案非常好。大多数时候，即使 merge 很长的分支，您也不会遇到重大问题。我通常一次 merge 所有内容，只有 如果 我遇到大量冲突，我才会备份并重新运行 merge 。即便如此，我还是大块地做。作为一个非常真实的例子，我有一个同事有 3 个月的 merge 更改，并且在 250000 行代码库中遇到了大约 9000 个冲突。我们所做的修复是一次进行一个月的 merge :冲突不会线性累积，分段进行会导致 远 少于 9000 个冲突。这仍然是很多工作，但不如一次提交一个那么多。