在现代软件开发中，Git 几乎是每个程序员的标配。然而，很多刚从“个人单打独斗”转向“团队多人协作”的小白，往往会被Git Rebase（变基）和PR（Pull Request/Merge Request，拉取请求）这两个词搞得一头雾水。有人觉得它们是高深的大佬黑科技，有人则把它们视为容易引发代码冲突的“大魔王”。
今天，我们就用最通俗的大白话，把 Git Rebase 的底层逻辑、PR 的协作机制，以及如何在单位内部团队中落地这套工作流彻底聊透。
一、 重新认识 Git Rebase：优雅的“代码时光机”
在多人协作时，我们经常从主分支（main）切出一个新分支（feature）去开发新功能。在你闭关写代码的几天里，同事们可能已经往main提交了新的代码。这时候，你的分支就落后于主分支了。
为了让你的分支拥有最新的基础代码，你通常有两种选择：
git merge（合并）：简单粗暴，把main的代码拉过来和你的代码揉在一起，生成一个新的“合并提交”（Merge Commit）。它的缺点是会让 Git 历史线变成错综复杂的“蜘蛛网”。git rebase（变基）：优雅细腻。顾名思义，改变分支的基点。它会把你整条分支“剪切”下来，然后贴到main分支最顶端的提交后面。
一个生动的比喻：
假设你在写一本书的第三章，这时候编辑修改了第一章和第二章。
- Merge：你直接在第三章后面补了几页，写着：“把前面编辑改的内容也加到我这里”。（历史线变复杂）
- Rebase：你把第三章整章拿过去，重新排版，假装自己是在编辑修改完第一、二章之后，才开始写第三章的。（历史线变成一条干净的直线）
Rebase 的核心使用场景
- 场景 A：同步远程主分支的最新代码（最常用）
在提交代码前，把本地功能分支接到主分支的屁股后面：
gitcheckout main&&gitpullgitcheckout feature-logingitrebase main- 场景 B：交互式 Rebase（整理提交记录）
本地提交太碎了（比如连续提交了fix bug、test等垃圾信息），在推送到远程前，可以把它们合并成一个体面的提交：
# 修改最近 3 次的提交，将后续提交 squash（压扁）到第一个提交中gitrebase-iHEAD~3⚠️ 黄金铁律：绝对不要在公共分支上使用 Rebase！
Rebase 会修改历史提交的 ID（Hash 值）。请只在你自己的、未分享给别人的私有分支上做 rebase。如果你去 rebase 别人正在使用的公共分支，会导致整个团队的历史线错乱，引发灾难。
二、 什么是 PR？怎样交出一份体面的“申请书”？
当你用 Rebase 把本地的代码整理得干净整洁后，下一步就是把代码融入主分支，这就涉及到了PR（Pull Request，在 GitLab 中被称为 MR，Merge Request）。
严格来说，PR 不是 Git 本身自带的命令，而是 GitHub、GitLab、Gitee 等代码托管平台提供的一种团队协作机制。
你可以把它理解为一份“申请书”：
“老大/各位同仁，我自己分支上的新功能（
feature-login）已经写好并用 rebase 整理干净了，请求你们检查一下，没问题的话帮我合并到main分支吧！”
PR 谁来做？
- 发起 PR 的人：开发人员（你）。功能写完并
git push到远程后由你主动发起。 - 审批/合并 PR 的人：项目负责人（Maintainer）或组内同事（Reviewer）。他们检查无误后，点击网页上的“Merge”按钮，代码才正式进入
main。
PR 的标准执行流程
- 本地推送：确保代码在独立分支，推送到远程：
git push origin feature-login。 - 网页发起：打开 GitHub/GitLab 项目主页，点击弹出的“Compare & pull request”（或手动新建 PR）。
- 填写信息：撰写清晰的 Title（如
feat: 增加用户微信登录功能）和 Description（改了什么、怎么验证），并指派评审人（Reviewers）。 - 代码评审（Code Review）：同事在网页上逐行审阅你的代码，提出修改意见。如果需要修改，你不需要关闭 PR，只需在本地改完继续
commit和push，PR 会自动更新。 - 合入主干：评审通过（Approve）后，点击“Merge pull request”，代码正式上线。
三、 融会贯通：单位内部多人合作项目，如何引入这套流派？
很多传统团队或单位内部项目习惯了大家直接往main或develop分支上push代码，认为引入 PR 和 Rebase 会增加工作量。事实上，这正是项目频繁产生 Bug、上线崩溃的根源。
在单位内部项目中推行“Rebase + PR”协作流，会带来颠覆性的质量提升：
1. 内部推行 PR 的三大核心价值
- 建立天然的防火墙（Code Review）：任何烂代码或明显的 Bug 在合并前必须经过至少一个同事的眼睛，御敌于国门之外。
- 打破信息孤岛与新人培养：新人通过提 PR、老员工带看，能最快熟悉团队规范；团队成员间也能通过看彼此的 PR 了解系统最新动态。
- 保证主分支的绝对稳定：确保
main分支的代码随时可打包、随时可发布。
2. 团队内部落地的最佳实践（工作流模型）
为了让团队成员不产生排斥心理，推荐采用“同仓库分支合作模式”，并结合 Rebase 保持历史整洁。标准协作闭环如下：
[main 分支] ───────────────────────────────────────────────► (保持绝对稳定) │ ▲ │ 切出新分支 │ PR 评审通过 (Merge) ▼ │ [feature 分支] ──► 写代码 ──► git rebase main (同步) ──┘- 各司其职：每个人在本地为新任务建立独立分支，绝不直接在本地
main编写代码。 - 先变基，后提单：在网页上发起 PR 之前，开发者必须在本地执行一次
git rebase main。
技术修养：这样做可以把所有潜在的冲突在本地解决掉，递交给老大的 PR 永远是“绿色的、无冲突的、提交记录一条直线的”。
- 渐进式规则：
- 初期：允许大家自己提 PR 自己合，重在习惯“在网页上留下评审和修改记录”。
- 中期：开启分支保护，规定核心分支（如
main、develop）禁止直接 Push，且必须获得至少一个同事的Approve才能合并。
四、 总结：从小白到高手的蜕变
| 工具/机制 | 它的核心本质 | 小白避坑指南 |
|---|---|---|
git rebase | 整理历史的“时光机”，让分支线变成直线。 | 只能在自己的私有功能分支上用，绝不动公共分支。 |
Pull Request | 团队协作的“申请书”，代码评审的载体。 | 提 PR 前先在本地 rebase 主干，解决冲突，保证 PR 清爽。 |
从各写各的、互相覆盖，到熟练运用git rebase整理逻辑，再到通过PR进行高效率的代码评审——这不仅是工具使用习惯的改变，更是从“个人作坊式开发”向“正规军团队协作”迈出的关键一步。
勇敢地在你的下一个内部项目中开启 PR 吧，你的团队一定会感谢那个交出整洁代码历史线的你！
