1

我在一个分支上开发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
4

1 回答 1

1

你的问题是squash commits盒子。您没有将提交直接合并feature_1到feature_4一个新的、压缩的提交，它引入了相同的更改。v_0.2由于您尝试合并另一个压扁的提交，因此合并现在存在冲突，部分引入了相同的更改。

从 gits 的角度来看，当您尝试合并dev到stablewithv_0.2时，相同文件上的更改stable未启用dev（来自压缩的合并提交）以及dev未启用stable的更改（新更改以及从feature_1到 4的更改，因为这些提交不是stables 历史的一部分，所以只引入了更改）。

我认为这里最好的解决方案不是将更改从dev合并到stable. 您也可以通过合并或重新基于 来解决此stable问题dev，dev但这stable会使事情变得更加混乱。

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

于 2018-04-04T10:54:44.607 回答