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



我有一个问题,我觉得这将是许多人的常见问题。但是,我找不到我的问题的任何答案。

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

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

我已经为我的存储库配置了写入访问权限,在分支masterdevelop上,只能通过拉取请求。对于所有其他分支,都给予完全权限,即任何人都可以向他们推送代码。

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

  1. 不久前发布了一个版本。它被合并到origin/masterorigin/develop
  2. 发展仍在继续;feature分支是通过拉取请求创建并合并到origin/develop中的。
  3. 实时代码中发现了一个严重的错误(origin/master)。
  4. master创建了一个hotfix分支,我们称之为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 结束。对开发所做的更改可能会破坏主控。

一种解决方案是,我可以非常小心,并确保在开始处理要开发的拉取请求之前完成任何要主控的拉取请求。在我看来,这并不理想。这既有风险(如果我忘记了怎么办),又阻碍了进一步的开发(在 master 完成之前,没有人可以开始通过修补程序的拉取请求进行开发):

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

探索

基于上述

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

提前致谢

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

我认为我们可以将这个hotfix/some-hotfix分支合并到主节点中。之后,我们可以将主分支合并到origin/develop中以获取master分支的最新代码,或者我们可以使用master重定origin/develop分支的基数。我认为合并更好。合并/变基后develop您必须解决分支中的冲突master

最新更新