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

Question

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

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

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

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

作为控制台输出：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

Answer 1

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

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

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

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