如何将一个分支偶尔合并到另一个分支

时间:2018-04-04 09:49:19

标签: git gitlab squash git-squash

我在分支dev上开发,每隔几周就想将当前状态合并到分支staging中。似乎我没有想到这一点,因为现在我想第二次这样做,我得到一个冲突,因为最后一个共同的祖先仍然是从我分开dev时 - 和第一次在单独的提交中将差异添加到staging

我在两种情况下都使用了gitlab合并请求,并选中了squash commits框。

我的做法本质上是错误的,我需要切换到不同的东西,还是有办法让它发挥作用?

如图:v_0.2合并失败。我想要做的是5-7的樱桃选择,我曾希望gitlab会理解,因为我已经合并了1-4的功能。但事实并非如此。

enter image description here

作为控制台输出:ffc9a2c这两个分支的最后一个共同父项(显然,那里发生的合并将该提交正确地作为新父项),之后我开始了上面描述的合并方案。从那时起,您可以完整地看到staging。我省略了大部分dev,因为它真的很长。

git log from staging:
*   5ac9823 Merge branch 'dev' into 'staging'
|\  
| * 50bac27 Code update for v1.rc0.0
|/  
*   5f38284 Merge branch 'dev' into 'staging'
|\  
| *   ffc9a2c Merge branch 'formatting_fix' into 'dev'


git log from dev:
*   176971e Merge branch 'doctest_fix' into 'dev'
|\  
| * 4f0a423 Fix bug for doctest in filters.py
.
.
.
*   945d9ab Merge branch 'return_codes' into 'dev'  # v1.rc0.0 took place here
|\  
| * aed6133 Replace return codes 
.
.
.
|  
*   ffc9a2c Merge branch 'formatting_fix' into 'dev'
|\  
| * 0451416 Improving Error Message Quality

1 个答案:

答案 0 :(得分:1)

您的问题是squash commits框。您没有直接将提交feature_1合并到feature_4,而是引入了相同更改的新的压缩提交。 v_0.2合并现在有冲突,因为您尝试合并另一个压缩的提交,部分引入相同的更改。

从gits角度来看,当您尝试将devstable合并到v_0.2时,stable中的相同文件会发生更改{{1} (来自压缩的合并提交)以及dev中未dev上的更改(新更改以及从stable更改为4,因为这些提交不属于feature_1历史记录,只引入了更改。

我认为这里的最佳解决方案不是将stable的变化与dev合并而来。您也可以通过将stable合并到stable或在dev上重新定位dev来解决此问题,但这会让事情变得更加混乱。

哈希不必相同;在staging上部署修补程序并且不进行开发是没有问题的(从git的角度来看。就干净的工作流而言,修复某些东西至少是有问题的,并且将其合并回开发)