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 回答