4

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

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

我倾向于创建一个以基础为基础的新分支,在其production上挑选这些提交并将其合并到production

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

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

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

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

4

1 回答 1

5

您应该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,其他将稍后包含),我会:

  • 删除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')
于 2010-06-11T11:52:31.957 回答