【问题标题】:Automatically deleting branches when completing pull requests完成拉取请求时自动删除分支
【发布时间】:2017-03-26 03:28:06
【问题描述】:

我的公司使用 VSTS 和 git。当我在 VSTS 中向开发分支完成拉取请求时,会自动选中删除功能分支的复选框,但除非我更改功能分支的权限以允许我是管理员用户组,否则它不会删除重写和销毁历史的成员(强制推送)。

每次我完成一个拉取请求时都这样做有点乏味,但我并不喜欢让这个管理员用户组的所有成员能够一直删除功能分支的想法。似乎可能有意外删除。当我正在完成一个经过审查和批准的拉取请求时,我确实对删除开发分支感到很自在。就权限而言,是否有第三种选择?贵公司如何制定能够删除功能分支的政策?

【问题讨论】:

  • "destroy history for the feature branch" - 没有分支历史这样的东西(虽然这是一个常见的错误)。可以将分支简化为指向特定提交的指针(无论如何,这都是 git 存储的内容):如果我在“.git/refs/heads/master”文件中查看,我会为我的一个项目(这是提交)得到“a1781736795d91a44a4cd4557b06011c6dbba96e” id 主分支当前打开)
  • 该权限称为重写和销毁历史(强制推送)。我已经更新了我的问题以反映这一点。

标签: git azure-devops git-branch pull-request


【解决方案1】:

恕我直言,我认为您应该将完成拉取请求的责任推给分支所有者/公关创建者。您可能已经知道您可以在 PR 上将某些人(阅读:主要开发人员)设置为“必需”,甚至可以根据正在更改的 repo 中的目录或区域过滤这些自动添加的人(我们使用人群)。

这将允许您和您其他受信任的开发人员审查所做的代码更改,并防止 PR 创建者在没有权威人士批准更改的情况下将任何代码放入您的 developmaster 分支。 PR的实际完成其实只是一个象征性的动作。真正有用的信息是知道谁批准了请求。

让分支和 PR 所有者对其功能分支和 PR 负责将缓解您更改分支权限的问题,以便您(不是分支所有者)可以删除其他人的分支。它还将缓解错误删除问题,因为所有者应该知道该功能何时完成。

另外恕我直言,如果该功能没有完成,完成,它不应该获得 PR。

还要注意,删除 AzDO 中的源分支不会影响本地存储库,直到有人执行 git remote prune origin 或选择的 IDE 定期为它们执行此操作,因此如果错误删除了功能分支,则应该是开发工作站上某个地方的至少一个副本。我们不使用“定期修剪我的遥控器”选项,这也是部分原因。

【讨论】:

    【解决方案2】:

    删除源分支需要对应分支的重写和销毁历史(强制推送)权限。

    默认情况下,分支所有者拥有删除分支(新分支)的权限。对于其他分支,您可以为指定分支指定特定用户的权限,不需要为整个组指定该权限,之后您不需要每次都指定权限。 (选择一个分支,点击添加=>添加用户)

    总而言之,有两种方法可以做到,1:由拉取请求审查者创建分支。 2:为拉取请求审阅者授予重写和销毁历史记录(强制推送)权限。

    【讨论】:

      【解决方案3】:

      我自己没有使用过 VSTS,但是在其他 git 主机(gitlab 和 github)中,有一个东西叫做“受保护的分支”。

      对于这些受保护的分支(我的工作流程中的“主”和“开发”),我覆盖了不允许开发人员删除这些分支的权限(他们可以随意删除其他分支)

      编辑

      我的记忆有问题。无法删除受保护的分支(使用 git;它们仍然可以使用 gitlab 网页删除)。可以设置允许接受合并请求和推送到分支的权限(见截图)。

      【讨论】:

      • 类似于VSTSbranch permissions,你只是保护master和develop。我希望有一种基于上下文设置权限的方法,这样您就可以获得仅适用于完成拉取请求的上下文的权限。
      猜你喜欢
      • 1970-01-01
      • 2021-09-24
      • 2020-11-25
      • 1970-01-01
      • 1970-01-01
      • 2012-12-25
      • 2014-04-04
      • 2013-11-29
      • 2014-11-30
      相关资源
      最近更新 更多