问题标签 [azure-repos]

我需要限制 azure repos 中特定用户组跨 50 个 repos 的某些分支的权限。也就是说，特定的一组用户不能强制推送到 master 分支，但可以强制推送到其他分支。

这在界面中很容易做到，但需要转到 50 多个存储库并手动执行此任务。我一直在阅读 Azure repos API 文档，但我很难了解如何进行设置？

我正在尝试在分支级别限制特定 AD 组的权限。以前，我曾询问 Microsoft Azure DevOps 团队是否有任何端点 URI REST API 用于此请求，但我得到的响应是它当前不可用。但是，我已经设法使用 chrome 开发人员工具获取 API，该工具是

然后，我使用下面的这个主体发出 POST 请求，

许可令牌的格式为 ,

描述符标识符是我们可以得到的。

在这里，我一直在获取 branchID。例如，如果我们试图限制的分支是master, support%5E，我们如何使用开发者工具获取这些分支 ID？

我想导入 Azure DevOps 项目中存在的存储库，是否可以导入该存储库及其拉取请求历史记录？

我们正在使用支持版本的 gitflow 工作流，并且我们也在使用 PR（功能 -> 开发 [squash]，修补程序 -> 支持/xx，修补程序 -> 开发，发布/xx -> 主）

问题是发布的拉取请求并不严格等同于“git flow release finish”，特别是因为没有将标签添加到master（您还需要另一个PR来开发）。

修补程序的问题是相同的（您有 2 个 PR 要做，并且未标记 support/xx）

可以解决问题的一件事是能够在 PR 被接受时在 PR 的目标分支上添加标签。

您知道围绕该用例是否可以进行一些自动化？

我在 Azure Repos 中实现了基于主干的开发，如下所示：

1. 短期功能分支的开发 - 多次提交
2. PR 到主干 - 合并壁球，删除功能分支
3. Cherry pick from trunk to release - Azure Repos 做了一个新的 PR，因此有一个新的提交 id
4. 将发布分支合并到 master - 基本合并保留历史
5. 修复后删除发布分支。

Azure Repos 或 git 中是否有工具实际上可以检查来自主干的哪些提交没有最终进入 master？

我在 Visual Studio 中创建了一个数据库项目，其中包括模式、表、存储过程和表。我已将它们添加到 Azure Repos 的源代码管理中。我只想将存储过程和视图发布到另一个数据库（它们具有相同的表模式）。

当项目在 azure 管道中构建时，它将为所有数据库对象创建构建，并且发布管道会将这些更改发布到数据库。有什么办法可以排除表，只构建和发布存储过程和视图？

Is it possible to create automatic pull requests against a specific branch on Azure Repos as PR triggers do not work in Azure Repos. I am new to working with Azure repos and any help would be appreciated. Thank you.

我们的组织拥有用于我们工作目的的私有 Azure-DevOps(VSTS) 存储库。现在，我的一位同事创建了一个私人 GitHub 存储库，我在其中被添加为合作者来做一些项目。

我无法从 Github 克隆存储库，我得到了

连接github.com 443端口失败：超时

为了解决这个问题，我为 GitHub 存储库添加了 SSH 密钥，现在我可以克隆它了。

现在的问题是，当我尝试在我的 VSTS 存储库中克隆或执行任何 Git 操作时，我得到了这个，

Git 因致命错误而失败。无法访问“ https://XXXX.visualstudio.com/YYY/_git/ZZZ/ ”：无法连接到 github.com 端口 1080：超时。

我也可以尝试通过在 VSTS 中添加 ssh 密钥来解决此问题，但我不想这样做，因为这意味着我需要再次克隆本地系统中的所有存储库（超过 30 个）才能继续工作它。

我们有一个安装了 Azure Dev Ops 的服务器，我们不使用任何远程目录来处理存储库。一切都在这台服务器上完成。

我们在服务器上的 C:/WorkSpace 文件夹中创建了一个项目。该项目已添加到 Visual Studio 源代码管理中。

三位开发人员通过 RDP 访问服务器，他们在安装在服务器上的 Visual Studio 上工作。每个开发人员都使用他或她的凭据通过 RDP 登录到服务器。我们从主项目创建了三个分支。我们的结构如下所示：

• IP 地址\默认集合
  • 项目名称
    • Dev1Branch
    • Dev2Branch
    • Dev3 分支
    • 主枝

当开发人员需要工作时，她会将 MainBranch 合并到她的分支中，然后在她的分支上工作。工作完成后，她提交她的分支，然后将其合并到 MainBranch，然后在 MainBranch 上进行最终提交。

上面的结构是好的还是我们遗漏了什么？

我们遇到的问题是，当开发人员正在处理一个文件时，她和第二个开发人员也在处理同一个文件，然后开发人员 1 将该文件排除在签入之外。如果将来进行任何更改，那么这些排除的文件没有被跟踪。

因此，Azure DevOps UI 现在支持设置跨存储库策略以保护所有现有和未来存储库的默认（主）分支 - 很好！

到目前为止，我们对每个存储库都使用了相同的策略，每当添加新存储库时手动设置它（我们正在为每个服务使用一个存储库来做微服务）。其中一项策略是构建验证。这是唯一一个从 repo 到 repo 的策略，因为每个 repo 都有自己的构建管道（目前是经典的，因为 YAML 仍然缺少一些关键功能）以及给定存储库的 Git 触发器。

问题是; 如果我设置了跨仓库策略并希望包含构建验证，那么鉴于每个仓库都有自己的构建管道，我该怎么做？AFAIK 构建管道（尚）不支持多个存储库作为触发器（对于 YAML 管道，这应该很快就会出现），因此我无法创建单个构建管道以用于所有存储库。