用途
create-pr 用于按照 Sentry 的工程实践创建 Pull Request。当你需要打开 PR、撰写 PR 描述，或为代码评审准备改动时，可以使用该技能。它帮助你把改动整理成符合 Sentry 代码评审与提交信息规范的 PR。
前置要求
需要已安装并完成认证的 GitHub CLI（gh），且该命令可用。
主要流程
第一步：验证分支状态
使用以下命令检查当前分支与状态：
git status
git log main..HEAD --oneline
需要确保：所有改动都已提交；分支与远程保持同步；如有需要，改动已基于 main 变基。
第二步：分析改动
查看将要包含在 PR 中的内容：
# 查看将进入 PR 的所有提交
git log main..HEAD
# 查看完整 diff
git diff main...HEAD
在撰写描述之前，先理解所有改动的范围与目的。
第三步：撰写 PR 描述
遵循以下结构：
- 简要说明该 PR 做了什么
- 为什么进行这些改动（动机）
- 考虑过的替代方案（如有）
- 评审者需要的任何额外上下文
不要包含：
- “Test plan”部分
- 测试步骤的复选框列表
- 对 diff 的冗余摘要
应当包含：
- 对“做了什么”和“为什么”的清晰解释
- 相关 issue 或工单的链接
- 从代码中不易看出的上下文
- 需要仔细评审的特定区域的说明
第四步：创建 PR
gh pr create --title "<type>(<scope>): <description>" --body "$(cat <<'EOF'
<description body here>
EOF
)"
标题格式遵循提交约定，例如：
- feat(scope): Add new feature
- fix(scope): Fix the bug
- ref: Refactor something
第五步：添加评审者（如已知）
# 请求特定人员评审
gh pr edit --add-reviewer username1,username2
# 或请求某个团队评审
gh pr edit --add-reviewer @getsentry/team-name
评审者数量限制在 1-3 人，以保持清晰的责任归属。
PR 描述示例
功能 PR
标题：Add Slack thread replies for alert notifications
正文：当告警被更新或解决时，我们现在会在原始 Slack 线程中发布回复，而不是创建新消息。这样可以让相关通知保持分组，并减少频道噪音。此前曾考虑对原始消息进行编辑，但使用线程能更好地保留事件时间线，并且在原始消息早于 Slack 编辑窗口时仍然有效。Refs SENTRY-1234
缺陷修复 PR
标题：Handle null response in user API endpoint
正文：用户端点对于软删除账户可能返回 null，导致访问用户属性时仪表盘崩溃。此改动添加了 null 检查并返回正确的 404 响应。在调查 SENTRY-5678 时发现。Fixes SENTRY-5678
重构 PR
标题：Extract validation logic to shared module
正文：将 alerts、issues 和 projects 端点中重复的验证代码移动到共享的验证器类中。无行为变更。这是为了在 SENTRY-9999 中添加新的验证规则做准备，避免在各端点间重复逻辑。
Issue 引用
在 PR 正文中引用 issue：
| 语法 | 效果 |
|---|---|
| Fixes #1234 | 合并时关闭 GitHub issue |
| Fixes SENTRY-1234 | 关闭 Sentry issue |
| Refs GH-1234 | 仅链接，不关闭 |
| Refs LINEAR-ABC-123 | 链接 Linear issue |
指导原则
- 每个功能/修复一个 PR——不要捆绑无关改动
- 保持 PR 可评审——更小的 PR 能获得更快、更好的评审
- 解释“为什么”——代码展示“做了什么”，描述解释“为什么”
- 尽早标记 WIP——使用草稿 PR 获取早期反馈
参考
- Sentry Code Review Guidelines
- Sentry Commit Messages