# 34. 变基
## 目的
> 使用 `rebase` 命令代替 `merge` 命令。
好,我们回到了第一次合并前的时间点,并且我们想要将 master 中的更改集成到 greet 分支。
这次我们将使用 `rebase` 命令代替 `merge` 命令来从 master 分支中引入更改。
```
$ git checkout greet
$ git rebase master
$ git hist
```
```
$ go greet
Switched to branch 'greet'
$
$ git rebase master
First, rewinding head to replay your work on top of it...
Applying: added Greeter class
Applying: hello uses Greeter
Applying: updated Rakefile
$
$ git hist
* 2fae0b2 2013-04-13 | Updated Rakefile (HEAD, greet) [Jim Weirich]
* 1c23048 2013-04-13 | Hello uses Greeter [Jim Weirich]
* 62d7ce0 2013-04-13 | Added greeter class [Jim Weirich]
* b59a8c2 2013-04-13 | Added README (master) [Jim Weirich]
* 96ee164 2013-04-13 | Added a Rakefile. [Jim Weirich]
* 0f36766 2013-04-13 | Moved hello.rb to lib [Jim Weirich]
* eb30103 2013-04-13 | Add an author/email comment [Jim Weirich]
* 1f7ec5e 2013-04-13 | Added a comment (v1) [Jim Weirich]
* 582495a 2013-04-13 | Added a default value (v1-beta) [Jim Weirich]
* 323e28d 2013-04-13 | Using ARGV [Jim Weirich]
* 9416416 2013-04-13 | First Commit [Jim Weirich]
```
### 合并 VS 变基
变基的最终结果与合并很相似。greet 分支现在包含它的全部 更改以及来自 master 分支中的所有更改。然而,提交树却十 分不同。greet 分支的提交树已被重写,以致 master 分支成 为了其提交历史的一部分。这使提交链更加线性,且更易阅读。
### 何时变基,何时合并?
不要使用变基……
如果是公开且与其他人共享的分支,那么重写公开的共享分支 将会搞砸团队中的其他会员。
要是提交分支的精确历史重要(因为变基将重写提交历史)。
根据上述准则,我会针对短期生命的本地分支使用变基,而对 公开仓库的分支使用合并。
- 关于
- 1. 设置
- 2. 再谈设置
- 3. 创建项目
- 4. 检查状态
- 5. 做更改
- 6. 暂存更改
- 7. 暂存与提交
- 8. 提交更改
- 9. 更改而非文件
- 10. 历史
- 11. 别名
- 12. 获得旧版本
- 13. 给版本打标签
- 14. 撤销本地更改
- 15. 撤销暂存的更改
- 16. 撤销提交的更改
- 17. 从分支移除提交
- 18. 移除 oops 标签
- 19. 修正提交
- 20. 移动文件
- 21. 再谈结构
- 22. Git 内幕:.git 目录
- 23. Git 内幕:直接处理 Git 对象
- 24. 创建分支
- 25. 导航分支
- 26. 在 master 中更改
- 27. 查看分叉的分支
- 28. 合并
- 29. 创建冲突
- 30. 解决冲突
- 31. 变基 VS 合并
- 32. 重置 greet 分支
- 33. 重置 master 分支
- 34. 变基
- 35. 合并回 master
- 36. 多个仓库
- 37. 克隆仓库
- 38. 回顾克隆的仓库
- 39. 何为 Origin?
- 40. 远程分支
- 41. 更改原始仓库
- 42. 取得更改
- 43. 合并拉下的更改
- 44. 拉下更改
- 45. 添加跟踪的分支
- 46. 裸仓库
- 47. 添加远程仓库
- 48. 推送更改
- 49. 拉下共享的更改
- 50. 托管你的 Git 仓库
- 51. 共享仓库
- 52. 高级/将来的主题