pull request（pr）是代码托管平台基于git分支实现的协作流程，非git原生命令；需推送非默认分支至有写权限的仓库后，github才显示pr按钮，或用gh cli工具创建。
GitHub 上的 Pull Request（PR）不是 Git 本身的功能，而是 GitHub（或 GitLab、Bitbucket 等平台）基于 Git 分支机制实现的协作流程。直接在本地运行 git 命令无法“创建 PR”，必须通过平台 Web 界面或 CLI 工具（如 gh）触发。
为什么 git push 后没看到 PR 按钮？
常见错觉是“推了代码就自动有 PR”，其实 PR 是独立于推送的操作。GitHub 只会在你推送一个**非默认分支**（比如 feature/login）后，在仓库主页顶部显示绿色 “Compare & pull request” 按钮——但这个按钮只对**你有写权限的仓库**生效。
- 如果你 fork 过原仓库（比如把
owner/repofork 成yourname/repo），必须先git push到自己的 fork，再从 fork 页面发起 PR 到上游（upstream） - 如果直接克隆的是主仓库（
git clone https://github.com/owner/repo.git），且你有 collaborator 权限，那推到新分支后，PR 按钮才可见 - 用
git status确认当前分支已 track 远程分支：git branch -u origin/feature/x，否则git push可能失败或推到错地方
用 gh CLI 快速提交 PR（免网页操作）
GitHub 官方 CLI 工具 gh 能跳过浏览器，一条命令完成 PR 创建。前提是已登录（gh auth login）且本地分支已推送到远程。
- 确保远程已配置：若 fork 了项目，需添加上游：
git remote add upstream https://github.com/owner/repo.git - 推分支：
git push -u origin feature/auth - 创建 PR：
gh pr create --title "Add JWT validation" --body "Fixes #123" --base main --head feature/auth - 注意：
--base是目标分支（通常是main或develop），--head是你当前分支名；如果省略--head，gh默认用当前分支
PR 描述里写什么才不被拒？
维护者扫一眼描述就能判断是否该点进去看代码。空着、写“fix bug”或贴大段日志，基本会被打回重写。
- 第一行标题必须明确动词开头：
Add/Fix/Refactor，避免Update或Change这类模糊词 - 正文中至少包含：
What（改了什么）、Why（为什么这么改，关联 issue 编号如Resolves #45）、How（关键实现思路，非代码细节） - 不要粘贴
git diff输出；需要展示效果可附截图或 curl 示例，但仅当必要 - 如果涉及数据库变更或 API 修改，必须单独加小节说明迁移方式或兼容性影响
PR 不是提交代码的终点，而是协作的起点。最常被忽略的是：没检查 CI 是否全绿、没确认是否更新了对应文档、以及在多人协作仓库中忘了 git fetch upstream && git rebase upstream/main 同步最新变更——这些都会让 review 卡住，比代码本身还耗时。
