合并请求Pull Request
Git 专区提交一组改动供检查，确认后再并入主版本
合并请求是 GitHub 等平台上的改动评审页面，不是 git 命令。创建时要说明目的、改动、验证方式和已知风险，再查看差异、运行检查并决定是否合并。
main
feat/dark-mode审查通过
$ gh pr create --title "首页深色模式"
PR 不是 git 命令，是 GitHub 网页上的评审卡：分支 push 上去后开单，请人看完改动、审查通过才合进 main。
什么时候用
- 把分支推到远程后，在托管平台创建合并请求feat/dark-mode 刚 push 上来feat/dark-modeCompare & pull request
- 标题写清改了什么，说明补上怎么验证，review 的人才接得住feat: 首页加上深色模式改了什么：导航栏 + 卡片支持深色
怎么验证：切换右上角开关 - 按照项目约定选择合并、压缩合并或变基Squash and merge ▾Create a merge commitSquash and mergeRebase and merge7 条试探 commit 压成 1 条进主干
- 一个人玩也走 PR：每次大改都留一份带说明的档案，日后好查Merged#12 feat: 深色模式Merged#11 fix: 手机端导航换行一个人玩也留了一份改动档案
什么时候不用
- 把 Pull Request 当成可以在终端直接运行的 git 命令$ git pull-requestgit: 'pull-request' is not a git command.PR 是 GitHub 的网页功能，不是命令
- 标题写 「update」「改了点东西」，说明空白，三天后自己都看不懂Openupdate #14说明空白，三天后自己都看不懂改了啥
- 一个 PR 塞三个功能、37 个文件：太大没人敢看，拆小再提Files changed 37+2,140 −867一个 PR 塞三个功能，没人敢 review
- 不看项目约定就合并：wip、试试这类提交让历史难以追溯提交说明：
● wip
● 试试
● 再试试
● 终于好了没按项目约定整理历史，之后很难追溯
组成结构 · Anatomy
● Openfeat: 首页加上深色模式 #12
xiao-hu 想把 feat/dark-mode 合并进 main
ConversationCommits 3Checks ✓Files changed 2
✓ 没有冲突，可以自动合并Squash and merge ▾
1标题与编号Title & #一句话说清改了什么；#12 是这张申请单的编号
2分支对Branches从哪个分支合进哪个分支：feat/dark-mode → main
3对话与改动TabsConversation 讨论、Commits 存档点、Files changed 逐行改动
4合并按钮Merge Button检查、测试和审批通过后再点；合并方式遵循项目约定
常见变体 · Variants
Squash and mergeSquash
3 commits → 压成 1 条进 main
想把一组试探提交整理成一个完整改动时
Create a merge commitMerge Commit
每条 commit 原样保留 + 合并节点
需要保留完整过程记录时用
Rebase and mergeRebase
commits 排队接到 main 尾巴上
历史一条直线，没有合并节点
典型使用场景
GitHub 开 PR 页
PR 对话与 review
Files changed 看改动
按项目约定选择合并方式