Question

我正在开发一个大型Rails项目，我正在使用的团队正在使用Github来管理项目。虽然许多更改都在本地进行，然后直接推送到我们的开发分支，但是当我们要进行大规模的更改时，我们会创建一个分支。当将该分支合并回开发时，我经常尝试将我的功能分支合并到开发之前重新开发回我的功能分支（以防止覆盖其他人的工作）。我发现当我这样做时，我似乎遇到了两次相同的合并冲突。我在重新定位时遇到了整个冲突列表，然后在合并时再次遇到相同的冲突列表。在将我的功能合并到develop之前，我是否应该将其发展为我的功能分支？或者我应该将我的功能合并到develop中？

假设我的功能分支称为“new_feature”。我将它与“开发”分支合并的过程如下：

git checkout develop 

git pull (this is set up on our rig to always pull rebase)

git checkout new_feature 

git rebase develop 

(lots of merge conflicts ensue) 

git checkout develop  

git merge -no-ff new_feature 

(same set of merge conflicts again)

就好像时间轴从我的rebase改变了，导致我的新功能分支一直发展为镜像，然后与psudo-copy本身发生冲突。

Answer 1

好的，现在这个评论太长了。

用手册（git help rebase）

来解释

   Assume the following history exists and the current branch is "new_feature":

                 A---B---C new_feature
                /
           D---E---F---G develop


   From this point, the result of either of the following commands:

       git rebase develop
       git rebase develop new_feature

   would be:

                         A'--B'--C' <new_feature
                        /
           D---E---F---G <develop

现在，如果您遇到冲突，首次运行rebase后的实际状态将为

              A'--B'--C'--[local state]
             /        ^
D---E---F---G          new_feature
            ^ develop

其中[local state]是您尚未解决的冲突合并。解决合并冲突并将已解析的文件添加到索引后，运行git rebase --continue：现在您的状态将是

              A'--B'--C'--H <new_feature
             /
D---E---F---G <develop

显然，在这一点上将new_feature合并到开发上可以像这样快速转发：

              A'--B'--C'--H <new_feature  <develop
             /
D---E---F---G

但如果不是，你会得到这个

              A'--B'--C'--H <new_feature
             /             \
D---E---F---G---------------I <develop

现在从时间轴的角度来看，无论你喜欢哪一个，都不明显为什么要么有问题......除非你从未完成过rebase并解决了与H的冲突，但我会认为git会抱怨这个。

Answer 2

听起来像你正在向后使用rebase，但它可能只是一个令人困惑的措辞。

我将功能分支重新设置为 develop，然后（在开发时）执行git merge --ff-only feature。

Answer 3

由于您在同一问题中指定“大规模”和“变基”，我建议您不要这样做。改为使用合并。

在合并中使用--no-ff非常适合保留原始分支点。我支持使用它。

当我使用Git时，我应该在合并之前进行重组吗？

3 个答案: