Git Cherry-pick vs合并工作流程

假设我是仓库的维护者，并且想从贡献者那里获取更改，那么可能有一些工作流程：

1. 我cherry-pick每个人都从远程提交（按顺序）。在这种情况下，git将提交记录为与远程分支无关。
2. 我merge分支，拉动所有的变化，并增加了新的“冲突”提交（如果需要）。
3. 我merge每个人都从远程分支分别提交（再次按顺序提交），从而允许为每个提交记录冲突，而不是将所有冲突归为一个组。
4. 为了完整起见，您可以做一个rebase（与cherry-pick选项相同？），但是我的理解是，这可能会使贡献者感到困惑。也许消除了选项1。

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

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

这两个rebase（和cherry-pick），并merge有自己的优点和缺点。我在merge这里主张，但是两者都值得理解。（在此处找到一个替代的，争论不休的答案，列举了rebase首选的情况。）

merge优于cherry-pick和rebase一对夫妇的原因。

1. 坚固性。的的SHA1标识提交识别它不仅在其本身，而且相对于它前面的所有其他的提交。这样可以保证给定SHA1上所有克隆的存储库状态都相同。从理论上讲，几乎没有人进行过相同的更改，但实际上是在破坏或劫持您的存储库。您可以选择单个更改，它们可能是相同的，但是您不能保证。（作为次要的次要问题，如果其他人再次在同一提交中进行新的挑选，则新的挑选出的承诺将占用额外的空间，因为即使您的工作副本最终相同，它们也会出现在历史记录中。）
2. 易于使用。人们倾向于merge相当容易地理解工作流程。 rebase往往被认为更高级。最好同时理解两者，但是不想成为版本控制专家的人（根据我的经验，其中包括许多非常擅长于他们的工作，但又不想花费额外时间的同事）会更轻松时间只是合并。

即使是繁重的工作流程rebase，cherry-pick在某些情况下仍然有用：

1. merge混乱的历史是其缺点之一。 rebase可以防止一连串的提交分散在您的历史记录中，就像您定期合并其他人的更改一样。实际上，这就是我使用它的主要目的。您要非常小心，永远不要rebase编码与其他存储库共享的代码。一旦完成了提交，push其他人可能已经在其上提交了，重新定基充其量将最多导致上面讨论的那种重复。在最坏的情况下，您可能会得到一个非常混乱的存储库和细微的错误，这将使您花费很长的时间来查找。
2. cherry-pick 有助于从您基本上决定放弃的主题分支中抽取一小部分更改，但是意识到其中有一些有用的内容。

至于更喜欢将许多更改合并为一个：这只是简单得多。一旦开始拥有大量变更集，那么合并各个变更集可能会变得非常乏味。git（以及Mercurial和Bazaar）中的合并分辨率非常好。大多数时候，即使合并很长的分支，您也不会遇到重大问题。通常，我会一次全部合并所有内容，并且只有在遇到大量冲突时，我才备份并重新运行合并程序。即使那样，我也会大块地做。作为一个非常真实的例子，我有一位同事，他有3个月的变更要合并，并且在250000行代码库中遇到了9000个冲突。我们要解决的问题是一次合并一个月的价值：冲突不是线性累积的，而逐步进行合并会产生很大的结果少于9000个冲突。这仍然是一项艰巨的工作，但不如一次完成一次提交那么多。

我认为应在需要的情况下保留樱桃采摘，例如，如果您直接在“主”分支（树干，主开发分支）上进行了一些修复，然后意识到也应将其应用于“维护” '。您应该基于合并或重新设置工作流（或“ git pull --rebase”）。

请记住，从Git（具有不同的SHA-1标识符）的角度来看，精心挑选或基于基础的提交不同于原始提交，因此它不同于远程存储库中的提交。（Rebase通常可以处理此问题，因为它检查补丁程序ID，即更改，而不是提交ID）。

同样在git中，您可以一次合并许多分支：所谓的octopus merge。请注意，章鱼合并必须成功而没有冲突。但是，它可能有用。

HTH。

Rebase和Cherry-pick是保持干净提交历史记录的唯一方法。避免使用合并，并避免产生合并冲突。如果使用的是gerrit，则在必要时将一个项目设置为Merge，将一个项目设置为Cherry-pick模式，然后尝试一下。