元数据卡： 前置知识：ch03-git-remote.md | 预计时间：10 分钟 | 阅读模式：选读 | 完成标志：了解 rebase 和 PR 工作流的基本概念
选读说明： 本节内容在你还是一人开发时不是必须掌握的。等到需要团队协作、规范分支策略时再回来看。
第七场战斗：想整理一下 Git 历史
你在实验分支上的新武器终于完成了。你兴冲冲地翻开工坊日志，准备登记你的成果——然后你看到了你的修改记录：
a1b2c3d 调试输出
d4e5f6g 修复拼写错误
g7h8i9j 临时保存
h0i1j2k 再试一次
l3m4n5o 实际实现的功能
p6q7r8s 改回来了"这也太难看了吧……"你嘀咕着。六条提交，真正有用的就一条。其他人看你的代码时，会看到一堆"调试输出"和"再试一次"。
你想把这几条垃圾 commit 压缩成一条干净的历史——用 rebase。
# 假设你在 feature 分支上，想合并最近 3 个 commit
git rebase -i HEAD~3语言： Bash 如何运行： 在要整理的分支上执行 预期输出： 打开编辑器，显示：
pick a1b2c3d 调试输出
pick d4e5f6g 修复拼写错误
pick g7h8i9j 实际实现的功能把前两个 pick 改成 squash（简写 s）：
pick a1b2c3d 调试输出
s d4e5f6g 修复拼写错误
s g7h8i9j 实际实现的功能保存退出。Git 会提示你写一个新的 commit message：
实现新功能
# 这是 3 个 commit 的合并结果结果： 原来 3 个乱糟糟的 commit 变成了 1 个干净的 实现新功能。
Rebase 的黄金法则： 永远不要 rebase 已经推送到共享远程仓库的分支。因为 rebase 会重写提交历史——别人已经基于旧历史做了工作，你重写历史会让他们崩溃。这条规则只适用于你本地还没推送的分支。
试试看： 在你的练习分支上创建 3 个 commit（比如在 file.txt 追加三行），然后运行 git rebase -i HEAD~3，把后两个改成 squash。
第八场战斗：想给别人的项目提修改建议
你在开源项目里发现了一个小缺陷，你知道怎么改。
你复制了一份那个项目的代码（fork），改好了方案。但你发现一个问题：你不能把修改直接写回原项目维护者的仓库里。
GitHub 上有一个明确的答案：你不能直接推——但你可以请求他把你的改动拉进去。这就是 Pull Request（PR，在 GitLab 上叫 Merge Request）。
完整流程如下：
1. Fork → 在 GitHub 上复制一份项目到你的账号
2. Clone → 拉到本地
3. 创建分支 → git switch -c fix-bug-123
4. 修改代码、commit、push
5. 在 GitHub 上点击 "New Pull Request"当你点击 New Pull Request 后，GitHub 显示：
base: original/main ← 你要合并到的目标分支
compare: 你的用户名/fix-bug-123 ← 你的修改维护者收到 PR 后可以：
- 查看代码变更（Files changed tab）
- 逐行留言评论
- 要求你修改（你改完 push，PR 自动更新）
- 最终合并（Merge pull request）
PR 是 Git 工作流的核心。 它不仅仅是代码合并——它是一次代码评审（Code Review），是团队协作的基本单元。
工作流模型简介
单人开发可以随意分支。但在团队中，你需要一个可预测的分支策略。
GitHub Flow（最常用）
master（始终可部署）
│
└── feature-A ← 在这里改，改完提 PR → master
└── fix-bug-1 ← 修完提 PR → mastermaster永远是稳定的、可部署的- 任何修改都在独立分支上完成
- 通过 PR 合并到
master - 适合持续部署的项目
- 适合大多数团队
Git Flow（更严格）
适用于有正式发布周期的项目：
master（线上版本）
│
└── develop（日常开发）
│
├── feature/login（新功能开发）
└── release/1.2（发布准备，只修 bug）master是线上版本，develop是日常开发- 发布前创建
release/分支做最后的稳定性打磨 - 紧急 bug 直接从
master拉hotfix/分支 - 适合有明确发布周期的团队
下一步
基本原理都讲完了。但 Git 只有理论是不够的——你需要亲手做一遍。
下一节是 练习与排障——三个热身练习 + 排障场景 + 速查表。动手的时候到了。