git-pr

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

Generate PR Description

生成PR描述

Create a comprehensive pull request description based on the branch diff.
基于分支diff创建完整的拉取请求描述。

Process

流程

1. Gather Context

1. 收集上下文

bash
undefined
bash
undefined

Get current branch name

Get current branch name

git branch --show-current
git branch --show-current

Find base branch (usually main or master)

Find base branch (usually main or master)

git remote show origin | grep 'HEAD branch'
git remote show origin | grep 'HEAD branch'

Get all commits on this branch

Get all commits on this branch

git log main..HEAD --oneline
git log main..HEAD --oneline

Get the full diff

Get the full diff

git diff main...HEAD --stat git diff main...HEAD
undefined
git diff main...HEAD --stat git diff main...HEAD
undefined

2. Analyze Changes

2. 分析变更

Categorize the changes:
  • Features: New functionality
  • Fixes: Bug fixes
  • Refactors: Code improvements without behavior change
  • Docs: Documentation updates
  • Tests: Test additions/changes
  • Chores: Dependencies, configs, tooling
对变更进行分类:
  • 功能:新增的功能
  • 修复:漏洞修复
  • 重构:不改变原有行为的代码优化
  • 文档:文档更新
  • 测试:测试用例的新增/修改
  • 杂项:依赖、配置、工具相关调整

3. Generate PR Description

3. 生成PR描述

Use this format:
markdown
undefined
使用如下格式:
markdown
undefined

Summary

摘要

[2-3 sentences describing what this PR does and why]
[用2-3句话描述本PR的作用和背景原因]

Changes

变更内容

  • [Bullet point for each logical change]
  • [Group related file changes together]
  • [Focus on what changed, not how]
  • [每个逻辑变更对应一个要点]
  • [将相关的文件变更归类到一起]
  • [重点说明改了什么,而非实现方式]

Type of Change

变更类型

  • Bug fix (non-breaking change that fixes an issue)
  • New feature (non-breaking change that adds functionality)
  • Breaking change (fix or feature that causes existing functionality to change)
  • Refactor (no functional changes)
  • Documentation update
  • 漏洞修复(不破坏现有功能的问题修复)
  • 新功能(不破坏现有功能的功能新增)
  • 破坏性变更(会导致现有功能变动的修复或功能)
  • 重构(无功能层面的变动)
  • 文档更新

Testing

测试说明

[How was this tested? What should reviewers verify?]
  • Unit tests pass
  • Integration tests pass
  • Manual testing completed
[已完成哪些测试?评审人需要验证哪些内容?]
  • 单元测试通过
  • 集成测试通过
  • 已完成手动测试

Screenshots (if applicable)

截图(如适用)

[Add screenshots for UI changes]
[UI变更请添加对应截图]

Checklist

检查清单

  • My code follows the project's style guidelines
  • I have performed a self-review
  • I have added tests that prove my fix/feature works
  • New and existing unit tests pass locally
  • Any dependent changes have been merged

Generated with Claude Code
undefined
  • 我的代码符合项目的代码风格规范
  • 我已完成代码自审
  • 我已添加测试用例验证我的修复/功能可正常运行
  • 本地新老单元测试均运行通过
  • 所有依赖的变更均已合并

Generated with Claude Code
undefined

4. Determine Title

4. 确定标题

PR title format:
type(scope): description
Examples:
  • feat(auth): add OAuth2 login support
  • fix(api): handle null response from payment service
  • refactor(db): extract query builder into separate module
PR标题格式:
type(scope): description
示例:
  • feat(auth): add OAuth2 login support
  • fix(api): handle null response from payment service
  • refactor(db): extract query builder into separate module

5. Output

5. 输出

Provide:
  1. Suggested PR title
  2. Full PR description in markdown
  3. Suggested reviewers (if CODEOWNERS exists)
  4. Labels to add (if .github/labels.yml exists)
提供以下内容:
  1. 建议的PR标题
  2. Markdown格式的完整PR描述
  3. 建议的评审人(如果存在CODEOWNERS文件)
  4. 需要添加的标签(如果存在.github/labels.yml文件)

6. Create PR (Optional)

6. 创建PR(可选)

If user confirms, create the PR:
bash
gh pr create --title "..." --body "..."
如果用户确认,可直接创建PR:
bash
gh pr create --title "..." --body "..."

Guidelines

规范指南

  • Focus on why over what (the diff shows what)
  • Link to related issues:
    Fixes #123
    or
    Relates to #456
  • Call out breaking changes prominently
  • Mention any manual steps required post-merge
  • Keep bullet points scannable (one line each)
  • 重点说明「为什么改」而非「改了什么」(diff已经展示了改动内容)
  • 关联相关issue:
    Fixes #123
    Relates to #456
  • 显眼地标注破坏性变更
  • 提及合并后需要执行的手动操作步骤
  • 保持要点清晰易读(每行一个要点)