Question

我开始研究branchB。这是从branchA分支出来的。几个星期后，主线分支开发已经合并了很多提交.A和B分支都落后了。

--d1--d2--d3  ...2 weeks later...  --d253  develop
       \
        a1--a2--a3                         branchA
                   \
                    b1--b2--b3             branchB (current)

我想跟上开发分支的最新动态。并且更喜欢在最新的提交d253中将我的branchB重新开发。此外，来自branchA的所有提交都应忽略。这将避免我为解决合并冲突做出巨大努力（有很多）。因为我不是那个分支的维护者。我可以在我的branchB中重新创建我需要的依赖A.不确定我是否应该在rebase之前或之后这样做。

--d1--d2--d3  .....  --d253  develop
       \                  \
        a1--a2--a3         \
                            \
                             b1'--b2'--b3'

Q1。

是否正确

git checkout develop
git pull
git checkout branchB
git rebase --onto develop branchA

Q2。让我们假设冲突的数量非常重要，大约有30个文件。与git merge develop相比，rebase仍然是一个好方法吗？

Answer 1

Q1 - 嗯，这是执行你在图片中显示的命令，是的。如果分支b与分支a正交，我想这很好。我会毫不犹豫地这样做;有没有理由你不想将两个分支重新绑定到当前的d提交？

Q2 - 我没有注意到rebase与merge在解决冲突方面有很大差异。最大的区别在于，您指定的特定rebase不会包含a更改;这意味着如果a更改与d更改冲突，则您无需处理。（如果b更改与a更改重叠，我认为这不会被视为冲突本身，但很可能会导致代码处于损坏状态。）

真正的问题是，是否已与其他开发人员共享b次提交？如果是这样，那么通常不推荐将它们重新定位，因为它会给其他开发人员带来问题。

Answer 2

为了在开发时使用B的提交来修改branchB必须使用rebase --onto和3个参数：

git checkout branchB
git rebase --onto develop branchA branchB

感谢Git Tip of the Week: Rebasing Revisited“Rebasing to”部分提供了一个与此问题中描述的场景类似的示例。

同样在git-rebase documentation。为方便起见，这里转载：

首先让我们假设您的主题基于分支。例如，主题中开发的功能取决于下一步中的某些功能。

o---o---o---o---o                  master
     \
      o---o---o---o---o            next
                       \
                        o---o---o  topic

我们想要从分支主人分叉主题;例如，因为主题所依赖的功能被合并到更稳定的主分支中。我们希望我们的树看起来像这样：

o---o---o---o---o             master
    |            \
    |             o'--o'--o'  topic
     \
      o---o---o---o---o       next

我们可以使用以下命令获取此信息：

git rebase --onto master next topic

分支机构，如何在另一个分支机构上重组？

2 个答案: