Git：同步包含以前采用樱桃挑选的提交的分支与master

Question

在git中，当分支已经包含来自master的挑选提交时，将部署分支与master更新的最佳/最简单方法是什么，假设您要保留部署分支的历史记录。

情景：

1. 在过去的某个时间部署分支机构取决于主人。
2. 从主人那里挑选出来进行部署的其他提交，遗漏了其他一些提交。
3. 部署代码部署到生产环境。
4. 现在，部署需要与master完全同步以进行下一次部署。

问题是，如何轻松地执行第4步（避免任何合并冲突，因为没有任何唯一的提交部署，只有樱桃选择的更改）而不更改部署中的任何历史记录（我的理解是在此处进行重组） point可能会在部署中丢失历史记录，或者使获取部署的确切代码变得更加困难，但我很可能会误解为此。）

执行git merge master会产生许多冲突，这样可以避免，因为需要的只是部署的头部直接类似于master的头部（deploy不包含任何唯一的更改）。 / p>

Answer 1

根据我的经验，合并应该可以正常工作。 Git检测到已经应用了樱桃挑选的提交并在合并期间“忽略”它们。你试着合并吗？即使它失败了你也可以使用git轻松恢复并尝试不同的东西（可能是另一种合并策略，但我对此没有经验）。

如果您想要重新绑定并仍然使用已部署的代码，只需在要保留的代码中添加标记即可。 rebase将重写提交的历史记录，但标记仍将指向rebase之前的代码（commit）。

Answer 2

用迄今为止我能找到的最佳方法回答我自己的问题。下面的命令会将master合并到你的分支中，同时解决所有冲突，支持master（从你的分支结账运行）：

git merge -s recursive -X theirs origin/master

Answer 3

我认为这不是您期望的答案，但您可能应该稍微改进您的分支策略，并使用主题分支更精细。这样你就可以合并主题分支而不是主人的樱桃挑选。因此，您的主分支将所有主题分支合并，并且开发分支将合并一些主题分支。然后，您最终合并master on development以使deploy分支更新。这不能保证您可以避免冲突，但它更清晰，在规范的情况下，您可以解决更少的冲突。

当你挑选git时，它失去了识别樱桃采摘的提交和樱桃腌制的原始相同的能力。这就是冲突的来源。