ProGit2 项目解析：Git 变基（Rebasing）深度指南
【免费下载链接】progit2 Pro Git 2nd Edition 
项目地址: https://gitcode.com/gh_mirrors/pr/progit2
什么是变基
在 Git 版本控制系统中，变基（rebase）是一种强大的分支整合技术。与常见的合并（merge）操作不同，变基通过重新应用提交来创造更线性的项目历史。理解变基的工作原理和适用场景，是掌握 Git 高级用法的关键一步。
基础变基操作
变基与合并的对比
假设我们有以下分支结构：
- master 分支有提交 C1-C3
- experiment 分支从 C2 分出，有提交 C4
使用合并（merge）会创建一个新的合并提交 C5，保留两个分支的完整历史。而变基则是将 experiment 分支的更改（C4）重新应用到 master 分支的最新提交（C3）之上，生成新的提交 C4'。
变基命令示例：
git checkout experiment
git rebase master
变基完成后，master 分支可以快速前进（fast-forward）到 experiment 分支：
git checkout master
git merge experiment
变基的内部机制
Git 执行变基时会：
- 找到两个分支的共同祖先提交
- 提取当前分支每个提交引入的差异
- 将这些差异保存为临时文件
- 重置当前分支到目标分支的最新提交
- 依次应用保存的更改
高级变基技巧
选择性变基
考虑更复杂的分支结构：
- master 分支
- server 分支从 master 分出
- client 分支从 server 分出
如果只需要将 client 分支的更改（不包括 server 的更改）应用到 master，可以使用 --onto 选项：
git rebase --onto master server client
这个命令的意思是："取 client 分支，找出它与 server 分支分叉后的补丁，然后把这些补丁重新应用到 master 分支上"。
非检出分支变基
你甚至可以不检出目标分支就执行变基：
git rebase master server
这会自动检出 server 分支并将其变基到 master 分支上。
变基的风险与最佳实践
黄金法则
永远不要对已经推送到公共仓库的提交执行变基。变基会重写提交历史，创建实质上不同但内容相似的提交。如果其他人基于这些提交进行了工作，会导致历史混乱和合并冲突。
变基冲突的解决方案
如果不幸遇到他人变基了你正在依赖的提交，可以使用以下方法修复：
- 使用
git pull --rebase而非普通 pull - 或者手动执行：
git fetch
git rebase teamone/master
Git 会通过"patch-id"机制智能识别你的独特提交，并尝试将其应用到新的基础之上。
配置默认变基行为
为避免意外，可以设置 pull 时默认使用变基：
git config --global pull.rebase true
变基与合并的哲学之争
历史记录派观点
认为提交历史是项目发展的真实记录，不应人为修改。合并提交虽然"杂乱"，但真实反映了开发过程。
历史整洁派观点
认为提交历史是项目的"故事"，应该像出版书籍一样精心编辑。在合并到主分支前，应该清理提交历史使其更易理解。
实践建议
折中方案是：
- 本地分支：自由使用变基保持历史整洁
- 公共分支：只使用合并操作
- 团队协作：明确约定并统一使用方式
总结
变基是 Git 中一个强大但需要谨慎使用的工具。它能创造更清晰线性的提交历史，但也可能带来协作问题。掌握变基的关键在于理解其工作原理，遵守"不变更公共历史"的黄金法则，并根据团队实际情况制定合适的工作流程。
【免费下载链接】progit2 Pro Git 2nd Edition 项目地址: https://gitcode.com/gh_mirrors/pr/progit2
创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
