⚡

创建拉取请求Skill create-pull-request

这个技能通过GitHub CLI工具帮助开发人员创建规范的拉取请求，优化代码提交、分支管理和CI/CD流程，提升团队协作效率。关键词：GitHub、拉取请求、代码审查、CI/CD、DevOps、自动化、代码管理。

CI/CD 0 次安装 0 次浏览 更新于 3/15/2026

name: create-pull-request description: 创建遵循项目惯例的GitHub拉取请求。当用户请求创建PR、提交更改以供审查或打开拉取请求时使用。使用gh CLI工具处理提交分析、分支管理和PR创建。 license: MIT

创建拉取请求

这个技能指导您如何创建结构良好的GitHub拉取请求，遵循项目惯例和最佳实践。

先决条件检查

在继续之前，验证以下内容：

1. 检查是否安装了 gh CLI

gh --version

如果未安装，通知用户：

GitHub CLI (gh) 是必需的但未安装。请安装它：

2. 检查是否已通过GitHub认证

gh auth status

如果未认证，指导用户运行 gh auth login。

3. 检查相关技能

在创建PR之前，检查是否有任何与代码审查、CI或测试相关的技能可用。这些应首先作为先决条件调用。

查找描述包含以下内容的技能：

  • “review”（例如，代码审查、PR审查、网页设计指南）
  • “CI” 或 “ci-fix”（例如，修复CI失败）
  • “testing” 或 “test”（例如，运行测试、webapp测试）

如果存在此类技能，在继续PR创建之前调用它们。例如：

  • 如果存在 ci-fix 技能且CI失败，使用它来诊断和修复问题
  • 如果存在 web-design-guidelines 技能用于UI更改，使用它来审查更改
  • 如果存在测试技能，使用它来确保测试通过

只有在这些先决条件技能得到满足后才继续PR创建。

4. 验证干净的工作目录

git status

如果有未提交的更改，询问用户是否：

  • 将它们作为此PR的一部分提交
  • 临时存储它们
  • 丢弃它们（谨慎操作）

检查现有PR

在收集上下文之前，检查当前分支是否已存在PR：

gh pr list --head $(git branch --show-current) --json number,title,url

如果已存在PR：

  • 显示现有PR详细信息（编号、标题、URL）
  • 询问用户是否想要：
    • 查看现有PR: gh pr view
    • 更新现有PR（推送更多提交，PR将自动更新）
    • 关闭现有PR并创建新PR

只有在没有为此分支存在PR时才继续创建新PR。

收集上下文

1. 识别当前分支

git branch --show-current

确保不在 main 或 master 上。如果是，要求用户创建或切换到功能分支。

2. 查找基础分支

git remote show origin | grep "HEAD branch"

这通常是 main 或 master。

3. 分析与此PR相关的最近提交

git log origin/main..HEAD --oneline --no-decorate

审查这些提交以理解：

  • 引入了什么更改
  • PR的范围（单个功能/修复或多个更改）
  • 是否应压缩或重新组织提交

4. 审查差异

git diff origin/main..HEAD --stat

这显示哪些文件更改，并帮助识别更改类型。

信息收集

从可用上下文（提交消息、分支名称、更改的文件）收集以下信息：

要提取的信息

  1. 相关议题编号：在以下中查找模式如 #123、fixes #123 或 closes #123：

    • 提交消息
    • 分支名称（例如，fix/issue-123、feature/123-new-login）
    • 如果找到，将其包含在PR标题和/或描述中
    • 如果未找到，继续而不包含

  2. 描述：这解决了什么问题？为什么进行这些更改？

    • 从提交消息和差异推断
    • 描述所做的更改

  3. 更改类型：错误修复、新功能、破坏性更改、重构、外观、文档或工作流

    • 从提交消息和更改的文件确定

  4. 测试程序：这如何测试？什么可能中断？

    • 如果修改了测试文件，提及它们
    • 如果从更改中明显，描述测试方法

智能PR标题生成

PR标题应描述性强且有意义。避免通用标题如：

  • “initial commit”
  • “fix”
  • “update”
  • “changes”

相反，创建一个清晰总结更改的标题。考虑以下方法：

1. 常规提交格式

通过分析检查项目是否使用常规提交：

  • 提交消息中的模式如 feat:、fix:、docs:、refactor:、test:、chore:
  • 分支名称前缀如 feat/、fix/、docs/

如果检测到常规提交，在PR标题中使用适当的前缀：

  • feat: 添加用户认证与OAuth
  • fix: 解决数据处理中的内存泄漏
  • docs: 更新v2端点的API文档
  • refactor: 简化错误处理逻辑
  • test: 添加支付流的集成测试
  • chore: 更新依赖到最新版本

如果找到，包含议题编号：

  • feat: 添加用户认证与OAuth (#123)
  • fix(auth): 解决数据处理中的内存泄漏 (fixes #456)

2. 描述性总结

如果不使用常规提交，创建清晰、面向行动的标题：

  • 好：“为搜索结果添加分页”
  • 坏：“initial commit”
  • 好：“修复认证流中的竞态条件”
  • 坏：“fix bug”

如果找到，包含议题编号：

  • “为搜索结果添加分页 (#123)”
  • “修复认证流中的竞态条件 (fixes #456)”

3. 标题生成策略

  1. 查看最重要的提交消息（通常是第一个或最后一个）
  2. 从差异中识别主要更改（新功能、错误修复等）
  3. 提取链接的议题标题
  4. 如果这些都没有提供好标题，从更改的文件及其目的合成一个
  5. 如果在提交或分支名称中找到，在标题后附加议题编号

Git最佳实践

在创建PR之前，考虑这些最佳实践：

提交卫生

  1. 原子提交：每个提交应表示单个逻辑更改
  2. 清晰的提交消息：尽可能遵循常规提交格式
  3. 无合并提交：优先使用变基而不是合并，以保持历史清洁

分支管理

  1. 在最新的main上变基（如果需要）：

    git fetch origin
git rebase origin/main

  2. 如果合适，压缩：如果有许多小的“WIP”提交，考虑交互式变基：

    git rebase -i origin/main

    只有在提交看起来混乱且用户熟悉变基时才建议此操作。

推送更改

确保所有提交都已推送：

git push origin HEAD

如果分支已变基，可能需要：

git push origin HEAD --force-with-lease

创建拉取请求

重要：如果存在，阅读并使用 .github/pull_request_template.md 中的PR模板。PR正文格式应匹配模板结构。

填写模板时：

  • 如果在上下文中找到，包含议题编号（例如，Fixes #123、Closes #456）
  • 如果没有模板，创建清晰的描述，包括：
    • 更改摘要
    • 相关议题（如果找到）
    • 执行的测试
    • 任何破坏性更改或显著影响
  • 用从提交和上下文中收集的相关信息填写所有部分
  • 如果模板有，标记适当的“更改类型”复选框
  • 完成任何适用的清单项

草案PR决策

基于以下决定是否创建草案PR或常规PR：

使用 --draft 标志时：

  • 更改不完整或进行中，但您希望早期反馈
  • 测试当前失败，您需要帮助调试
  • 您在架构决策上受阻，需要指导
  • 将PR创建为您稍后将继续工作的书签
  • 您想触发CI检查但尚未准备好全面审查

使用常规PR（无 --draft）时：

  • 所有测试通过，代码已准备好审查
  • 更改完成，您对方法有信心
  • 您希望PR尽快被审查和合并

使用gh CLI创建PR

对于常规PR：

gh pr create --title "PR_TITLE" --body "PR_BODY" --base main

对于草案PR：

gh pr create --title "PR_TITLE" --body "PR_BODY" --base main --draft

创建后

创建PR后：

1. 在浏览器中打开PR进行验证

立即在浏览器中打开PR以验证它是否正确创建：

gh pr view --web

这允许您：

  • 验证PR标题和描述是否正确渲染
  • 检查所有链接是否有效（议题引用等）
  • 确保差异看起来符合预期
  • 查看任何立即的CI状态

2. 提醒CI检查

测试和代码检查将自动运行。监控检查以确保它们通过。

3. 建议后续步骤（如果需要）

  • 如果需要，添加审阅者：gh pr edit --add-reviewer USERNAME
  • 如果需要，添加标签：gh pr edit --add-label "bug"

错误处理

常见问题

  1. 在main之前没有提交：分支没有要提交的更改

    • 询问用户是否打算在另一个分支上工作

  2. 分支未推送：远程没有该分支

    • 首先推送分支：git push -u origin HEAD

  3. PR已存在：该分支已存在PR

    • 显示现有PR：gh pr view
    • 询问是否要更新它

  4. 合并冲突：分支与基础冲突

    • 指导用户解决冲突或变基

摘要清单

在最终确定之前，确保：

  • [ ] gh CLI 已安装并认证
  • [ ] 相关审查/CI/测试技能已被调用
  • [ ] 没有为此分支存在PR
  • [ ] 工作目录干净
  • [ ] 所有提交已推送
  • [ ] 分支与基础分支保持最新
  • [ ] PR标题描述性强且有意义（非通用）
  • [ ] 如果项目使用，PR标题使用常规提交格式
  • [ ] 如果在上下文中找到，在标题/描述中包含议题编号
  • [ ] PR描述遵循模板（如果模板存在）
  • [ ] 选择适当的更改类型
  • [ ] 选择正确的草案/常规状态
  • [ ] 在浏览器中打开PR进行验证