GitHub PR Writer
Generates structured, thorough PR descriptions using a consistent template.
Template
See assets/pull_request_template.md for the full template to copy into your repo's .github/pull_request_template.md.
How to Fill It
When writing a PR description, gather context first:
CODEBLOCK0
Then fill in each section:
Summary
One or two sentences. What does this PR do and why? Link the issue if there is one.
CODEBLOCK1
Type of Change
Check exactly one (or two if truly applicable). Be honest — don't check "safe" if there are breaking changes.
Implements / Fixes
Link issues or describe the specific feature/bug this addresses. Be specific enough that a reviewer knows what to look for.
Description of Changes
Bullet points — what actually changed in the code:
- - New files created
- Existing files modified and why
- Anything removed
- Config changes
- Database migrations
Group related changes together. Lead with the most important change.
Impact
Honest assessment. If you changed a shared concern, a base class, or anything that touches many parts of the app — flag it.
Testing Notes
Tell the reviewer how to verify the changes work:
- - What specs were added/changed
- Manual QA steps if needed
- Edge cases that were considered
- Anything that was intentionally NOT tested and why
Rules
- - Fill every section — empty sections signal an incomplete review
- Check appropriate checkboxes — don't leave all unchecked
- Be specific in Description — "Updated stuff" is not useful
- Be honest about Impact — reviewers need to know what to watch for
- Never merge — PRs are for review; the author or maintainer merges
Example (filled)
CODEBLOCK2
GitHub PR Writer
使用一致的模板生成结构化、全面的PR描述。
模板
请参阅 assets/pullrequesttemplate.md 获取完整模板，将其复制到你的仓库的 .github/pullrequesttemplate.md 中。
如何填写
编写PR描述时，先收集上下文信息：
bash
查看与基础分支相比的变化
git diff main --stat
查看提交信息
git log --oneline main..HEAD
查看完整差异（适用于较小的PR）
git diff main
然后填写每个部分：
摘要
一两句话。这个PR做了什么以及为什么？如果有相关问题，请链接。
text
关闭 #123
通过Devise添加用户认证，包含邮箱确认功能。
变更类型
勾选恰好一个（如果确实适用，可以勾选两个）。请诚实——如果有破坏性变更，不要勾选安全。
实现 / 修复
链接问题或描述此PR解决的具体功能/缺陷。描述要足够具体，让审查者知道需要关注什么。
变更描述
要点列表——代码中实际发生了什么变化：
- - 创建的新文件
- 修改的现有文件及原因
- 删除的内容
- 配置变更
- 数据库迁移
将相关变更分组。以最重要的变更开头。
影响
诚实的评估。如果你更改了共享关注点、基类或任何影响应用多个部分的内容——请标记出来。
测试说明
告诉审查者如何验证变更是否有效：
- - 添加/更改了哪些规范
- 如果需要，手动QA步骤
- 考虑到的边界情况
- 任何故意未测试的内容及原因
规则
- - 填写每个部分 —— 空部分表示审查不完整
- 勾选适当的复选框 —— 不要全部不勾选
- 描述要具体 —— 更新了内容没有帮助
- 对影响要诚实 —— 审查者需要知道需要注意什么
- 切勿自行合并 —— PR用于审查；由作者或维护者合并
示例（已填写）
markdown
📦 拉取请求
摘要
关闭 #44
为乘车预订添加司机可用性系统。当乘客请求乘车时，
系统根据排班窗口、现有乘车冲突和驾驶时间缓冲检查哪些已批准的司机可用。
✅ 合并前检查清单
代码
- - [x] 代码在本地运行无错误
- [x] 我的代码没有未使用或注释掉的部分
- [x] 我已审查过我的代码
- [x] 我已为任何复杂逻辑添加注释
测试
- - [x] 所有测试通过
- [x] 我已根据需要添加或更新测试
🧪 变更类型
🛠️ 实现 / 修复
实现第一阶段乘车排班的司机可用性检查。
📋 变更描述
- - 向 userrides 添加 role 列（司机/乘客，默认：乘客）
- 创建 driverschedules 表用于定期和一次性可用性窗口
- 添加 DriverSchedule 模型，包含 covers_time? 方法
- 添加 GeoapifyDriveTimeService 用于通过Geoapify路线矩阵API获取实时驾驶时间
- 添加 DriverAvailabilityService —— 4步可用性检查
- 更新种子数据和工厂以包含 role
💣 影响
🧪 测试说明
3个规范文件中共有75个新测试。最终测试套件：729个示例，0个失败。
