Azure devops 是否可以在Azure DevOps上从pull请求创建UI灰显受保护的分支？

我知道如何将合并限制在某些分支上，但是否可以在DevOps UI上的“目标”下拉列表中将受保护的分支灰显以创建PR？这将避免浪费大量时间，以免意外创建针对错误/不可访问分支的PRs

编辑：将标题和说明更改为灰色，而不是忽略受保护的分支。灵感来自Leo答案中的截图

编辑：我想为我的团队为什么需要这个提供一些背景：

---

几乎100%的时间，我们的PRs都会将功能分支的

dev

分支作为目标。其他1%可能正在从较新的功能分支合并到较旧的功能分支。我们已经锁定了我们的

qa

和

master

分支，并且仅在我们的发布周期PRs中针对这些分支，这是专门使用DevOps服务API创建的。因此，在目标分支下拉列表中选择

qa

和

master

实际上是零值。

显然，没有这样的功能。这就是分行政策的目的

在创建PR之前，它要求标题、描述、审阅者以及可能需要链接的工作项。然后，在填写信息并检查有更改的文件和提交之后，人们会有意识地决定单击按钮以提出请求。这足以阻止某人针对错误的分支创建公关

如果制定了正确的分支合并策略（如至少必须有“n”个审阅者批准、生成必须通过、工作项必须链接等），则即使提交了PR，也无法完成PR

即使公关是意外提出的，你仍然可以选择“放弃”公关

您还可以将相关的分支重命名为“{branch name}过时”或“{branch name}不使用”。最好是将这些分支全部删除。如果没有，请使用文件夹组织分支。将文件夹命名为“过时”或“请勿使用”，并将所有相关分支保留在该文件夹下

Azure DevOps上的拉请求创建UI是否可以省略受保护的分支

显然，Azure devops不支持这样的功能，并且个人认为MS将来不会添加这样的功能

这是因为如果我们在拉请求创建UI中忽略受保护的分支，那么当我们想要将代码合并到这些受保护的分支时，我们将无法在目标分支中找到这些受保护的分支。我们将无法再合并这些受保护分支上的任何代码，那么，创建这些受保护的分支将毫无意义

另一方面，公关是一个非常严重的问题。它将直接影响目标分支（正确合并或错误合并以销毁目标分支）。因此，在进行PR之前，我们必须非常清楚需要合并的目标分支，否则，即使我们忽略目标分支中受保护的分支，它仍可能损坏其他未受保护的分支，这将带来巨大风险。

最后但并非最不重要的一点，我了解您的需求，并希望减少因太多目标分支而导致的误操作。我宁愿为你提供一个避免它的好方法。创建Branch时，将所有受保护的分支放在特定文件夹中，如ProtectBranch。因此，当我们进行PR时，以下样式将出现在目标分支的下拉菜单中：

---

使用文件夹对目标分支进行分类将避免浪费大量时间，以免意外创建针对错误/无法访问分支的PRs。

感谢您花时间回答，Leo。IMO关于不允许隐藏不可访问的分支的演算缺少的是一个发布周期模式：我们的团队只允许特权用户从名为分支（dev/qa/master）的环境中合并，事实上，我们在发布计划中使用DevOps服务API以编程方式实现了这一点。因此，强迫用户完全依赖他们的眼球，而不是将他们的选择限制在允许分支的子集上，这使得我们没有一个符合人体工程学的解决方案。@ZevAverbach，谢谢你的解释。所以，你不能使用我回答的解决方法？如果是的话，我想不出更好的解决方案/解决办法。原因正如答案中所说：（.Leo，据我所知，仍然没有办法阻止选择那些

ProtectBranch/

-预先设置好的分支，对吗？它们仍然会出现在下拉列表中。如果您有时间，我将非常感谢您在我的问题中提供的额外上下文中的任何其他想法。如果

master

和

qa

（我们受保护的分支机构）可以出现在列表中，但变灰，这与我最初提出的让它们完全消失的问题一样好——如果不是更好的话。但这也不可能，对吗？@ZevAverbach，我同意你的看法，变灰会更好。但正如我在回答中所说，这一要求非常特殊，没有解决方案我们可以把这个用户的声音提交给我们的主要论坛以提供产品建议：但是它可能是在一个低优先级SRIDHAR，我感谢你花时间来回答。类似于我对雷欧的回答的评论，我不认为这样一个人类错误的解决方案是最佳的。通常是PR创建UI上的默认目标分支，我们永远不希望手动将该分支作为目标。