Git flow 工作流程 - 修补程序与分支权限冲突

Question

我有一个问题，我觉得这对很多人来说都是一个普遍的问题。但是，我无法找到我的问题的任何答案。

我有一个使用 git flow 工作流程(不使用 git-flow)的 bitbucket 存储库。但是，我目前在使用分支权限时遇到了一些工作流程问题。我有以下分支命名约定:

• 大师
• 开发
• 修补程序/...
• 发布/...
• 功能/...

我已经在分支 master 和 develop 上为我的存储库配置了写入权限，仅通过 pull 请求。对于所有其他分支，给予完全许可，即任何人都可以向它们推送代码。

我遇到的问题可以通过以下一系列操作来解释。

1. 不久前发布了一个版本。它被 merge 到 origin/master 和 origin/develop。
2. 开发仍在继续； feature 分支通过 pull requests 创建并 merge 到 origin/develop。
3. 在实时代码 (origin/master) 中发现了一个严重错误。
4. hotfix 分支是从 master 创建的，我们称它为 hotfix/some-hotfix。

5. 错误已修复，hotfix/some-hotfix 分支已推送到存储库。我们现在还有一个远程分支 origin/hotfix/some-hotfix。在这个阶段我们有:

   • origin/develop 是 origin/master 的负责人，通过多次提交(取决于开发进度)。
   • origin/hotfix/some-hotfix 是 master 的负责人(通过提交修复错误)。

6. 创建 pull 请求以将 origin/hotfix/some-hotfix merge 到 origin/master 中。这会很好地工作，因为 origin/hotfix/some-hotfix 是从 origin/master 创建的。

注意: pull 请求不一定已解决，即 origin/hotfix/some-hotfix 未 merge 到 origin/master 中。

1. 创建 pull 请求以将 origin/hotfix/some-hotfix merge 到 origin/develop 中。在许多情况下，这会导致冲突；对两个分支都进行了更改。

我无法将 origin/develop merge 到 origin/hotfix/some-hotfix 中，因为这个分支是要我 merge 到 origin/master。推送到 hotfix 分支的任何更改，在最终 pull request 到 master 之前，也将在 master 中结束。对 develop 所做的更改可能会破坏 master。

一个解决方案是，我可以非常小心并确保在开始处理要开发的 pull 请求之前完成任何对 master 的 pull 请求。在我看来，这并不理想。这既有风险(如果我忘记了怎么办)又会阻碍进一步的开发(在 master 完成之前，没有人可以开始通过 hotfix 的 pull request 进行开发):

我觉得这是这个工作流程的一个常见问题。

问题

基于以上

1. 我是否以错误的方式解释了 git flow 工作流程？
2. 你们是怎么做到的？
3. 我怎样才能解决这个问题，或者完全避免它？

提前致谢

Answer 1

不，您没有以错误的方式解释工作流程。

我认为我们可以将这个 hotfix/some-hotfix 分支 merge 到 master 中。之后，我们可以将 master 分支 merge 到 origin/develop 中，将 master 分支的最新代码获取到其中，或者我们可以 rebase origin/develop 与 master 的分支。我觉得 merge 比较好。 merge/ rebase master

后，您必须解决 develop 分支中的冲突