樱桃采摘与变基

Question

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

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

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

然后，当我合并master到生产时，我会遇到合并冲突，因为即使更改是相同的，但由于樱桃选择而注册为不同的提交。

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

虽然我没有做过太多的重新定位，但我相信这也会创建一个新的提交哈希。

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

Answer 1

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

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

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

With x1 and x2 needing to be included in production:

git checkout design
git rebase --interactive production

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

Then:

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

That allows you:

• to validate current design commits against the production commits (durung the rebase)
• reorder the design commits
• include the first ones in production
• allows subsequent merges from design to production to be a fast-forward one.

Lakshman Prasad adds:

I push the changes at the end of the day most of the time. So doesn't really help that much. How would your answer change for the pushed master branch

I would do the same, but with a private branch created just for the operation:

git checkout master
git checkout -b master-private

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

, then the rebase, this time with the private branch (i.e. a branch you won't ever push).

git rebase --interactive production

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

Then:

git checkout production
git merge x2'

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

master won't benefit from the commit reordering (with a more logical order), but at least you can push master whenever you want.

And production can still include exactly what it needs.
If subsequent commits to master have the same issue (some need to be included to production, other will later), I would:

• delete master-private (we don't really care about those x', copy of x commits from master)
• make a master-private branch on top of master
• re-do the rebase --interactive, with a crude conflict resolution tactic (except for the first commits of that master-private branch, since those ones need to be integrated in the production branch)

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