如何在不引发合并冲突集群的情况下将子分支作为即将进行的提交和合并的不同dev分支?

时间:2018-09-28 19:08:49

标签: git

所以我有这个布局...

Master
 \
  \
   Dev Branch
        \
         \
        Feature Branch A

但是在项目之间移动时,我将添加具有此布局的分支...

Master
 \      Feature Branch B
  \     /
   Dev Branch
        \
         \
        Feature Branch A

但这是棘手的部分... Feature Branch A具有有助于Feature Branch B的功能...

Master
 \      Feature Branch B (should start with code that's presently in A)
  \     /             ^
   Dev Branch         |
        \             |
         \            |
        Feature Branch A

最重要的是,在合并分支A或B之前,Dev Branch将获得其他将首先合并的分支,这两个分支都必须在重新同步之前合并,这意味着B不能基于A停留...

Master
 \      Feature Branch B (should start with code that's presently in A)
  \                      /  ^          /     \
   Dev Branch-------------- | ------- / ------------
   \     \    \             |        /       /
    \     \    \            |       /       /
     \     \  Feature Branch A---- / ------/
      \     \                /    /
       \     \              /    /
        \    Feature Branch 3   /
         \                     /
          Feature Branch Number 4

那么我该如何启动分支B到初始代码基于A的地方,但并不与之绑定,而是在技术上仍然基于Dev,以便以后可以将其他内容合并到其中,然后再合并到其中开发人员以后没有问题吗?我的意思是,我可以只分支开发人员,然后从A复制粘贴代码,但我希望以后避免这种荒谬的合并冲突。

1 个答案:

答案 0 :(得分:1)

如果仅需要来自其他功能分支的某些功能,则可以随时cherry pick them进入自己的功能分支。

或者,如果“ B”仍然需要“ A”中的所有内容,则只需rebase it位于“ A”的顶部,并具有“ A”中的所有功能。在冲突堆积如山之前,请定期定基础,以尽早发现任何冲突。

并且如果您将源文件保持简短且切合实际(即,没有文件包含数千行代码),则可以进一步减少遇到复杂冲突情况的机会。

此外,使用良好的编辑器或合并工具,可以更轻松地解决合并冲突。您可以从三个窗格中看到来自什么的东西。