0

与我一起工作的团队不接受master应该合并分支develop以develop与master's hot-fixes/bug-fixes 保持一致的事实。

他们害怕当他们以某种方式合并master（我们稳定的生产分支）到develop（所有功能分支合并到的分支尚未部署到生产中的分支）时，develop尚未测试的前期工作可能会丢失。

这发生了好几次（虽然不是发生在我身上），我们团队的某个人告诉我们“我合并master了它，它覆盖了X（另一个开发人员）develop所做的提前更改”。develop

所以，我想也许有人使用git的方式不正确，因为我在合并时没有遇到这个问题master，develop不知何故将旧版本带到develop了旧版本，而没有测试合并前的新东西。

关于为什么会发生这种情况的任何想法和想法？您认为当我们合并时我们有时会面临什么master问题develop？

我知道master一旦有热修复/错误修复就应该合并回开发中，否则develop不会有这个修复。我的同事一直认为这可能导致上述问题。谁是对的？

但是，从逻辑上讲，如果您合并master到develop中，则与合并master到您的分支中feature-branch-1然后将该分支feature-branch-1合并到中相同develop（在这种情况下，您只是将所做的更改带到master第三develop个分支中feature-branch-1）。你怎么看？

感谢关注！

编辑：我仍在调查，即使我接受答案，请告诉我你的想法，我想就这个事实获得尽可能多的意见。

4

1 回答 1

2

由于需要调查真实案例，您可以重新创建每个合并情况。签出来自 的父提交develop，合并来自 的父提交master。然后看看你是否有与历史相同的结果。

--A--C (develop)
    /
--B+ (master)

对于上述命令的历史记录将是：

$ git checkout -B test_merge A
$ git merge -m "testing merge C" B
$ git diff C

请注意，即使合并最终导致冲突，您也应该能够立即运行 diff 以评估冲突解决方案，或者尝试自己先解决它，然后与记录的版本进行比较。

我假设抱怨这一点的人可能正在使用一些-X(ours|theirs)标志或 GUI 冲突解决程序，它们鼓励一键“选择一方”。这是不正确的做法，那么双方都有独立的变化（如果你做得正确，你应该只有独立的变化）。

rerere 也可以记住不正确的分辨率，注意像“Resolved '***' using previous resolution”这样的行

但是，从逻辑上讲，如果您将 master 合并到 develop 中，这与将 master 合并到您的 feature-branch-1 然后将此分支 feature-branch-1 合并到 develop 相同（您只是将 master 上所做的更改通过 a第三个分支，在本例中为 feature-branch-1)。你怎么看？

我同意。没有区别。这都是级联工作流程的一个特例（链接中有自以为是的描述，但它有一个很好的图片）

于 2018-04-11T11:01:19.513 回答