从branch1启动branch2与从主服务器启动branch2并在branch1中合并

Question

我有一个功能分支(branch1)已经批准，但尚未合并到主配置项(必须等待部署配置项修复)。我想开始使用另一个分支(branch2)，它需要对分支1进行更改。在master上创建我的branch2，然后在branch1?...or中合并，只是在branch1上创建branch2，这是否更有意义？

这些方法之间有什么不同吗？

Answer 1

考虑一下这段历史：

-A--B--C--D   <- master
    \
     \--E--F  <- one

您需要在E和F中进行更改，因此在这里从one创建分支是正确的选择。如果提交C和D不存在，则分支master，然后合并one是完全相同的：

-A--B--C--D      <- master
    \
     \--E--F     <- one
            \
             \-  <- two

但是，如果您还需要在C和D中进行更改，则必须合并这两个分支。这既可以通过分支master并将one合并到其中来完成，也可以反过来完成。但请记住，这可能会产生您无法解决的合并冲突，最好是先等待负责的人将one合并到master中。

-A--B--C--D--     <- master
    \        \
     \--E--F  \    <- one
            \  \
             \--M  <- two (now contains all changes from A to F)

Answer 2

如果您需要像您所说的那样在branch1中进行这些更改，那么您应该从那里创建分支，否则您可能最终需要挑剔或重新实现逻辑。

这没什么坏处，分支机构已经批准了。只需确保它会在可能与之冲突的其他人之前被合并。即使这样，你也可以跳过解决冲突提交。

Answer 3

从另一个分支开始也可以。即使是来自未经批准的分支机构。唯一的问题是，在执行rebasing之类的操作时，您必须更加小心(特别是在使用未经批准的分支时)。诀窍是，当你使用这个技巧时，你应该假设你的基本分支可以改变(在你的例子中，它不会被合并，对吧？)。可以对基本分支进行重新基址、重新排序、修改或基本上任何操作。

例如，如果您选择重新设置分支的基址，则必须小心不要移动基础分支带来的更改。所以这可能意味着你必须做一些事情，比如：

git rebase --onto some-new-base tip-of-your-base-branch your-branch

(例如，这是您在分支中具有的基本分支的提示，而不是如果该分支已重新建立基础的新提示)

这样，您可以确保只移动更改，而不移动用作基础的分支的任何内容。