Question

使用git flow，它注意到hotfix分支从master分支并合并回master和develop。

然而，将hotfix合并到develop会导致合并冲突是合理的，这就是我的团队目前主张将hotfix合并到master的原因然后从master执行develop返回。

但我认为从hotfix到develop产生冲突的方案也会在merge到develop上产生冲突，因此不存在在这里受益。

更糟糕的是，因为他们总能解决GitHub Pull Requests中的冲突，如果从master到develop发生冲突，他们会在master解决时创建提交它在合并到develop之前。

毕竟，这些不是问题吗？从hotfix合并到master和develop真的那么重要还是第二种方法同样合适？

Answer 1

在实践中，这两种方法在功能上大部分时间都是相同的。

1       # last common commit
|\
| \
|  \
|   \
v    \
2     3  # master follows left side commits, develop follows right side
|\   /|
| \  .|
|  |  |
|. |  |
v/ |  |
4  |  |  # 4 merged into master from feature branch, contains 3
|  |  |
|  v  |
|  5  |  # hotfix commit 5
| /|  |
v/ |  |
6  |  |  # 6 fixes conflicts between 3 and 5
|   \ | 
|    \v 
|     A  # A also fixes conflicts between 3 and 5
 \
  \   .
   \  |
    \ |
     \v
      B # merge master with hotfix to develop

因此，您在A或B中合并开发的可能性是A将包含提交（1,2,3,5），B将包含（1,2,3， 4 ，5 ， 6 ）。无论出于何种原因，在开发分支中可能存在4或6中的任何内容，但实际上我看不出它是什么。

假设提交4来自于开发上的某些更改（已经在开发中），则提交5和提交4可能存在合并冲突。在这种特殊情况下，冲突必须在6和A中解决，而合并到B将允许仅在6中解决这些冲突一次。解决冲突两次也有可能（稍微）不同地解决它们，进一步导致合并未来的冲突。

从hoftix分支到掌握和开发分支的合并策略的差异

1 个答案: