樱桃采摘与变基

Question

以下是我经常遇到的一个场景：

您在master 或design 上有一组提交，我想将它们放在production 分支之上。

我倾向于创建一个新分支，其基础为productioncherry-pick 这些提交并将其合并到production

然后，当我将 master 合并到生产环境时，我面临合并冲突，因为即使更改是相同的，但由于cherry-pick而被注册为不同的提交。

我找到了一些解决方法来解决这个问题，所有这些方法都很费力，可以称为“hacks”。

尽管我没有做太多的变基，我相信这也会创建一个新的提交哈希。

我应该在我挑选的地方使用变基吗？与此相比，这还有什么其他优势。

Answer 1

您应该在生产之上创建一个rebase --interactive 您的设计分支，其中：

• 您可以重新排序提交，从生产中需要的提交开始
• 然后您可以将生产合并到您想要合并的设计的最后提交（快进）

-x--x--x1--x--x2（设计） \ p--p（生产）

x1 和 x2 需要包含在生产中：

git checkout design
git rebase --interactive production

-x
  \
   p--p (production)
       \ 
        x1'-x2'--x'--x' (design)

然后：

git checkout production
git merge x2'
-x
  \
   p--p--x1'--x2' (production)
                \
                 x'--x' (design)

这让你：

• 根据生产提交验证当前的设计提交（在变基期间）
• 重新排序设计提交
• 在生产中包含第一个
• 允许从设计到生产的后续合并快速推进。

---

Lakshman Prasad 补充：

我大部分时间都会在一天结束时推送更改。所以并没有那么大的帮助。对于推送的主分支，您的答案将如何变化

我也会这样做，但只为操作创建一个私有分支：

git checkout master
git checkout -b master-private

-x--x--x1--x--x2 (master, master-private) \ p--p（生产）

，然后是变基，这次是私有分支（即你永远不会推送的分支）。

git rebase --interactive production

-x--x--x1--x--x2 (master)
  \
   p--p (production)
       \ 
        x1'-x2'--x'--x' (master-private)

然后：

git checkout production
git merge x2'

-x--x--x1--x--x2 (master)
  \
   p--p--x1'--x2' (production)
                \
                 x'--x' (master-private)

master 不会从提交重新排序中受益（具有更合乎逻辑的顺序），但至少您可以随时推送master。

而且production 仍然可以准确包含它需要的内容。
如果后续对master 的提交也有同样的问题（有些需要包含在production 中，其他的会在以后），我会：

• delete master-private（我们并不真正关心那些 x'，来自 master 的 x 提交的副本）
• 在 master 上创建一个 master-private 分支
• 使用粗略的冲突解决策略重新执行rebase --interactive（master-private 分支的第一次提交除外，因为这些需要集成到production 分支中）

-x--x--x1--x--x2--x--x3--x (主) \ p--p--x1'--x2'--x3'（生产） | \ | x''--x'' (主-私有) \ x'..x'（来自第一个主-私有的旧 x'）