标签: pull-request

Azure devops 有一个“设置自动完成”按钮，如果 PR 符合为存储库设置的准则，则可以自动完成 PR。功能如何被禁用？我没有看到专门用于禁用它的切换开关或设置部分。

我有一个非常简单的设置。一个功能在功能分支中开发，然后被合并到develop并准备好足够的功能，我们想要进行合并提交master。所有这一切都应该通过拉取请求来发生。这背后的想法是隐藏最终出现在功能本身中develop/后面的各个提交的所有细节。master

目前，似乎不可能在不同的分支上实际强制执行不同的合并类型，如下所述：为每个分支设置拉取请求合并选项

更重要的是——这真的是一个好的策略吗？大多数从事此工作的人都是 Git 新手（包括我），因此我希望使其尽可能简单且安全。经过过去几个小时的谷歌搜索后，我找不到任何相关信息。

所以，我想我的问题是：设置此功能的简单方法或最佳方法是什么？其他人也有同样的问题吗？如果是这样 - 他们如何解决？或者这个问题仅仅是因为对 GitHub 不够了解而产生的？

您也可以向我指出任何建议、文档或最佳实践吗？

当我在问题发生后立即创建拉取请求时，拉取请求编号通常比问题编号大 1，这表明它们共享相同的计数器。同样，创建问题评论API 似乎是在拉取请求中评论主要讨论的主要方式，并且 API 请求issue_number. 然而，GitHub 上没有任何正式声明问题编号等于拉取请求编号。

是否有任何官方文档或评论可以验证拉取请求的问题编号是否等于其拉取请求编号？

对于 python 应用程序，我设置了一个 GitHub 操作，该操作在每个要掌握的拉取请求上运行 pytest（和其他工具）。

当工作流程失败时，我在拉取请求页面的“检查”选项卡中看到它，但即使 GitHub 操作失败，我也可以合并我的分支：

在我的存储库中，设置 -> 分支，我创建了一个符合我的需要的新保护规则，但我无法指定任何状态检查。

我想要做的就是使用我的工作流程来允许（或禁止）根据工作流程的输出合并拉取请求。

有任何想法吗？

我想将 master 重置为之前的提交，但我也想要一个 PR 供我的团队批准。

到目前为止我这样做了：

1. 从 master 创建本地分支
2. git重置--hard d94kjf8
3. 推送到远程

现在，当我进入 github 创建 PR 时，它会显示“master 与 mybranch 的所有提交都是最新的”，因此创建 PR 没有什么区别。

在使用我们的审核流程时，为了重置 master，我应该采取哪些不同的做法？

假设我有一个名为 acme/widget 的工作区和存储库，并且我有一个名为 brianc/widget 的分支。使用 BitBucket api，如何创建从我的存储库到上游的拉取请求？

在文档中似乎没有办法进行这种跨存储库拉取请求创建，因为这似乎branch是唯一允许的变量。有任何想法吗？

我们使用 Azure DevOps 进行持续集成。管道配置为每当将更改推送到功能分支时就运行构建。这是快速反馈所需要的。

此外，我们对主分支有一个政策，即在合并功能分支之前需要成功的验证构建。现在，当为功能分支创建拉取请求 (PR) 时，Azure DevOps 会自动触发相应的验证构建。

所有这些都很好，但有一个逆境：如果已经创建了 PR 并且更新了功能分支，则会触发两个构建（一个单独用于功能分支，另一个用于合并的结果，即验证构建） ）。

我知道有些人可能想要两个构建，但在我们的情况下（可能在每个正常情况下），如果仅触发验证构建会更好。

问题：有没有办法告诉 Azure DevOps 它应该忽略任何已拥有 PR 的分支的分支触发器？当然，具有同等结果的解决方法也是受欢迎的。

这个问题已经作为一个问题发布在这里，但我在回复中找不到令人满意的答案（例如，分支过滤器和命名策略不能解决问题）。

使用 Bitbucket REST API，我\xe2\x80\x99m 寻找一种方法来获取分配给用户的所有拉取请求。到目前为止，这个端点：https://api.bitbucket.org/2.0/repositories/{workspace}/{repository_name}/pullrequests/{pullrequest_id}?fields=reviewers将向我显示分配给该特定拉取请求 ID 的审阅者。有没有办法做到这一点，但不是针对特定的拉取请求，而是针对分配给用户的所有拉取请求？