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

Question

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

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

• master
• develop
• hotfix/...
• release/...
• feature/...

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

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

1. 不久前发布了一个版本。它被合并到origin/master 和origin/develop。
2. 继续开发；通过拉取请求创建feature 分支并合并到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 是大师的负责人（通过提交来修复错误）。

6. 创建拉取请求以将 origin/hotfix/some-hotfix 合并到 origin/master。这可以正常工作，因为origin/hotfix/some-hotfix 是从origin/master 创建的。

注意：拉取请求不一定被解析，即origin/hotfix/some-hotfix没有合并到origin/master中。

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

我无法将origin/develop 合并到origin/hotfix/some-hotfix，因为这个分支是为了我而合并到origin/master。在对 master 的最终拉取请求之前，推送到 hotfix 分支的任何更改也将在 master 中结束。对开发进行的更改可能会破坏 master。

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

我觉得这将是此工作流程的常见问题。

问题

基于上述

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

提前致谢

Answer 1

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

我认为我们可以将这个 hotfix/some-hotfix 分支合并到 master 中。之后，我们可以将 master 分支合并到origin/develop 中以获取master 分支的最新代码，或者我们可以将origin/develop 分支重新设置为master。我觉得合并比较好。在合并/重新定位 master 后，您必须解决 develop 分支中的冲突