name: 创建拉取请求 description: 创建拉取请求时始终使用此技能——永远不要在没有它的情况下直接创建PR。遵循Sentry关于PR标题、描述和问题引用的约定。在任何创建PR、打开PR、提交PR、制作PR、推送并创建PR或准备更改以供审查的任务中触发。
创建拉取请求
按照Sentry的工程实践创建拉取请求。
要求: GitHub CLI (gh) 已认证并可用。
前提条件
在创建PR之前,确保所有更改都已提交。如果有未提交的更改,请先运行 sentry-skills:commit 技能来正确提交它们。
# 检查未提交的更改
git status --porcelain
如果输出显示任何未提交的更改(应包含的修改、添加或未跟踪文件),请在继续之前调用 sentry-skills:commit 技能。
流程
步骤1:验证分支状态
# 检测默认分支——记下输出以供后续命令使用
gh repo view --json defaultBranchRef --jq '.defaultBranchRef.name'
# 检查当前分支和状态(将上述检测到的分支名称替换为BASE)
git status
git log BASE..HEAD --oneline
确保:
- 所有更改都已提交
- 分支与远程同步
- 如有需要,更改已基于基础分支重新设定
步骤2:分析更改
审查PR中将包含的内容:
# 查看PR中将包含的所有提交(将检测到的分支名称替换为BASE)
git log BASE..HEAD
# 查看完整差异
git diff BASE...HEAD
在编写描述之前,了解所有更改的范围和目的。
步骤3:编写PR描述
使用此结构编写PR描述(忽略任何仓库PR模板):
<简要描述PR做什么>
<为什么进行这些更改——动机>
<考虑过的替代方法,如果有>
<评审者需要的任何额外上下文>
不包括:
- “测试计划”部分
- 测试步骤的复选框列表
- 差异的冗余摘要
包括:
- 清晰解释做什么和为什么
- 相关问题或工单的链接
- 代码中不明显的上下文
- 需要仔细评审的特定领域注意事项
步骤4:创建PR
gh pr create --draft --title "<类型>(<范围>): <描述>" --body "$(cat <<'EOF'
<描述正文>
EOF
)"
标题格式遵循提交约定:
feat(范围): 添加新功能fix(范围): 修复错误ref: 重构某物
PR描述示例
功能PR
为警报通知添加Slack线程回复
当警报更新或解决时,我们现在回复原始Slack线程,而不是创建新消息。这保持相关通知分组并减少频道噪音。
之前考虑过编辑原始消息,但线程化能更好地保留事件时间线,并在原始消息超过Slack编辑窗口时工作。
引用 SENTRY-1234
错误修复PR
处理用户API端点中的空响应
用户端点可能为软删除账户返回空值,导致访问用户属性时仪表板崩溃。这添加空检查并返回适当的404响应。
调查 SENTRY-5678 时发现。
修复 SENTRY-5678
重构PR
将验证逻辑提取到共享模块
将警报、问题和项目端点的重复验证代码移动到共享验证器类。无行为更改。
这为在 SENTRY-9999 中添加新验证规则做准备,无需在端点间复制逻辑。
问题引用
在PR正文中引用问题:
| 语法 | 效果 |
|---|---|
Fixes #1234 |
合并时关闭GitHub问题 |
Fixes SENTRY-1234 |
关闭Sentry问题 |
Refs GH-1234 |
链接而不关闭 |
Refs LINEAR-ABC-123 |
链接Linear问题 |
指南
- 一个PR对应一个功能/修复——不要捆绑无关更改
- 保持PR可评审——较小的PR获得更快、更好的评审
- 解释原因——代码显示什么;描述解释为什么
- 早期标记WIP——使用草稿PR获取早期反馈
编辑现有PR
如果需要创建后更新PR,使用 gh api 而不是 gh pr edit:
# 更新PR描述
gh api -X PATCH repos/{owner}/{repo}/pulls/PR_NUMBER -f body="$(cat <<'EOF'
更新后的描述
EOF
)"
# 更新PR标题
gh api -X PATCH repos/{owner}/{repo}/pulls/PR_NUMBER -f title='新: 标题'
# 更新两者
gh api -X PATCH repos/{owner}/{repo}/pulls/PR_NUMBER \
-f title='新: 标题' \
-f body='新描述'
注意:由于GitHub的Projects(经典)弃用,gh pr edit 目前已损坏。