合并请求Pull Request
你可能会说
我改完了，想请人看一眼没问题，再合进正式版本。
合并请求是在 GitHub 或 GitLab 上查看改动、讨论并决定是否合并的页面。例如把新导航的改动上传后，可以创建一个合并请求；其他人能逐行查看变化、留言并确认自动检查结果，再决定是否合进主版本。它不是终端命令，也不表示改动已经进入主版本。
什么时候用
- 把功能分支 Push 到远程后，在 GitHub 创建 Pull Requestfeat/dark-mode 已推送到远程feat/dark-modeCompare & pull request
- 写清目的、主要改动、验证步骤和已知问题feat: 首页加上深色模式改了什么：导航栏 + 卡片支持深色
怎么验证：切换右上角开关 - 逐页查看改动清单，并等待必要的自动检查通过Squash and merge ▾Create a merge commitSquash and mergeRebase and merge将 7 条中间提交整理为 1 条主分支提交
- 确认反馈已经处理后，再按项目约定合入主版本Merged#12 feat: 深色模式Merged#11 fix: 手机端导航换行个人项目也可保留带说明的改动记录
什么时候不用
- 把 Pull Request 当成可以在终端直接运行的 Git 命令$ git pull-requestgit: 'pull-request' is not a git command.PR 是 GitHub 的网页功能，不是命令
- 只写“改好了”，没有说明目的和验证方式Openupdate #14标题与说明过于笼统，难以理解改动范围
- 没有查看改动内容，只因为自动检查通过就直接合入Files changed 37+2,140 −867一个 PR 包含三个功能，评审范围过大
- 收到反馈后继续修改，却没有重新检查最新变化提交说明：
● wip
● 调整实现
● 修正样式
● 完成修改未按项目约定整理历史，后续追溯会更困难
组成结构 · Anatomy
● Openfeat: 首页加上深色模式 #12
xiao-hu 想把 feat/dark-mode 合并进 main
ConversationCommits 3Checks ✓Files changed 2
✓ 没有冲突，可以自动合并Squash and merge ▾
一句话说清改了什么；#12 是这张申请单的编号
从哪个分支合进哪个分支：feat/dark-mode → main
Conversation 讨论、Commits 存档点、Files changed 逐行改动
检查、测试和审批通过后再点；合并方式遵循项目约定
常见变体 · 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 看改动
按项目约定选择合并方式
延伸阅读 · 权威出处