标签: pull-request

我正在按照本教程创建拉取请求。在第 3 步中，他们提到在使用存储库时创建分支是一个很好的做法。但我觉得如果我将更改推送到分叉存储库的主分支，那么在发出拉取请求时不会产生任何影响。

很奇怪的是，我的代码在我的笔记本电脑中通过了所有 UT/IT，但在 github CI 中却遇到了错误。您介意帮忙学习一些在 github CI 中调试的方法吗？或者让代码像github一样在本地运行？

这是一个关于时间序列数据库 Apache-IoTDB 的项目。该错误看起来像是普通代码中的一个微不足道的逻辑错误。希望它可以帮助诊断错误。非常感谢 ！

我在文件夹中制作了ISSUE_TEMPLATE和，并为每个文件夹制作了自定义模板。PULL_REQUEST_TEMPLATE.github

在 GitHub 中，当我创建问题时，GitHub 会询问我想要哪些问题模板，但不是用于 PR，我需要使用 URL 参数。

在写PR之前有没有办法选择PR模板？

每当打开要掌握的 PR 时，我们都会尝试自动将 DevOps 组添加为默认 PR 审阅者。

为此，我们在 master 分支中创建了一个 CODEOWNERS 文件，并将我们的 DevOps 组添加为审阅者。如果我们在 dev 分支中创建一个 CODEOWNERS 文件，在该文件中，我们不会指定 DevOps 组作为审阅者，而是指定开发团队（我们只需要 DevOps 作为 master），则任何时候从 dev 到 master 的 PR 被打开时，CODEOWNERS 都会合并时被覆盖。

我们如何防止覆盖 PR 上的 CODEOWNERS 文件？

我非常确定 GitHub 使用相同的计数器来处理问题、拉取请求和讨论。

如果我在一个全新的存储库中创建一个问题，它的编号将为#1。然后，如果我想创建一个拉取请求，分配给它的编号将是#2。同样，如果我随后创建一个讨论，其编号将为#3。

我只是想对我的猜测进行某种确认，但在 GitHub 文档中找不到任何内容。

有人可以证实这一点吗？

当审阅者选项卡上没有该选项时，如何将 GitHub PR 更改为草稿？

我已经看到了一些与审阅者选项卡下可用的按钮相关的答案，但我的没有显示（如下面的屏幕截图所示）

我尝试switch to draft在审阅者选项卡下找到该按钮，但它没有显示在我的 PR 上。

GitHub 允许创建PR 模板。除了拉取请求审查之外，是否可以做同样的事情？

例如，添加审核清单，如下所示：

- [] Have all the GitHub checks passed?
- [] Is there any redundant code?
- [] Could any optimization be applied?

我们使用代码所有者文件自动将评论分配给拉取请求。我们还让 Dependabot 为主要版本创建 PR。

我们不想自动向 Dependabot 创建的 PR 添加评论。根据https://docs.github.com/en/repositories/managing-your-repositorys-settings-and-features/customizing-your-repository/about-code-owners#codeowners-syntax，不可能!使用排除。

有没有办法：

• 对除用户之外的所有已创建 PR 使用代码所有者
• 不对 Dependabot 创建的 PR 分配审阅者

谢谢！

我已阅读 Codeowners 文件和 Dependabot 的文档。https://docs.github.com/en/code-security/dependabot/dependabot-version-updates/customizing-dependency-updates#setting-reviewers-and-assignees

我们不会在 Dependabot 操作中使用任何评论。

我尝试在推送到我的分支后创建一个新的拉取请求，因为我想将我的分支合并到主分支中。GitHub 的回应是“这个分支有冲突需要解决”。但是，冲突如此复杂，我应该在本地解决。对此的建议是：
步骤 1：克隆存储库或使用最新更改更新本地存储库。
git pull origin main
步骤2：切换到拉取请求的头分支。
git checkout myBrach
步骤3：将基础分支合并到头部分支。
git merge main
步骤4：修复冲突并提交结果。
有关解决合并冲突的分步说明，请参阅使用命令行解决合并冲突。
第 5 步：推送更改。
git push -u origin myBranch

但是当git merge main我收到以下错误后：

error: Your local changes to the following files would be overwritten by merge:  
 ... // Files listed  
Merge with strategy ort failed.  

我认为这个建议将帮助我更新 myBranch 并删除“main 后面的提交”。我不知道这个错误Merge with strategy ort failed意味着什么以及如何在不丢失代码的情况下解决这个问题。

假设两个开发人员正在处理不同的 PR。他们各自的 PR 包含相同的文件，其中有版本号。作为 PR 的一部分，两位开发者都打算提高这个版本号。如何确保第二个合并 PR 进行开发的人，即使只比第一个开发人员晚一秒钟，相对于第一个开发人员的版本号会增加版本号？PR 的合并是在 GitHub 中完成的。

版本是开放的 API 规范编号。存储库中实际上有几个这样的文档。请注意，在第一个 PR 之后合并的 PR 中不会出现合并冲突，因为两个开发人员都会使用相同的版本。

我想要的是：

1. Dev 1 的首次提交：1.123.0
2. Dev 2 的第二次提交：1.124.0

实际发生的情况：

1. Dev 1 的首次提交：1.123.0
2. Dev 2 的第二次提交：1.123.0