git 鼓励大量使用分支---"早建分支!多用分支!",这是因为即便创建再多的分支也不会造成存储或内存开销,并且分支的作用有助于我们分解逻辑工作,这样一样其实比维护单一臃肿分支要简单得多!
正因如此,每个新功能会创建合并分支,修复 bug 会创建合并分支等等,一段时间后再次回顾整个版本库的提交历史就会发现分支错综复杂,难以理清!
虽然"条条大路通罗马",但错综复杂的道路容易让人迷失方向,如果不使用分支,当然就不存在"分叉问题",所以在某些情况下我们希望寻求一种替代方案来解决分支合并带来的"分叉问题"!
回顾提交历史
查看提交历史: git log --pretty=oneline --graph --abbrev-commit
仅仅是简单的演示项目的提交历史都已经出现"分叉问题",更何况真实的企业级开发项目呢?如果真的是多分支多人合作开发的话,"分叉现象"将更加明显,模拟效果图大概长这样:
整理提交历史
如果想要一条直路直达罗马,那我们必须规划好路径,摒弃小道,坚持主干道.git的各种 dev,feature等分支就是需要治理的一条条分叉小道,而 master 主分支就是我们的大道.
演示项目有三个分支,主干master,开发dev,自定义snow,目标是将自定义 snow 分支的工作成功整理合并到主干分支,从而解决"分叉问题",dev 分支与项目演示无关,无需更改.
(1). 切换到 snow 分支并提交一个版本(learn git rebase)
(2). 切换到 master 分支也提交一个版本(modify README)
(3). 切换回 snow 分支,整理提交历史(git rebase)到 master 分支
(4). 切换回 master 主干分支再次变基合并 snow 分支
(5). 整理分支完成,最终主干分支是一条直线
这一次我们没有使用 git merge 而是采用 git rebase 方式完成了分支的合并,优点是提交历史更清晰,缺点是丢失了分支信息.
小结
git rebase 变基合并分支,实际上就是取出一系列的提交版本并“复制”到目标版本,从而形成一条新的提交历史线.
比如我们想要把 bugFix 分支里的工作直接移到 master 分支上,移动以后会使得两个分支的功能看起来像是按顺序开发,但实际上它们是并行开发的,这就是 git rebase 的作用.
git rebase 的优势是创造更线性的提交历史,使得代码库的提交历史变得异常清晰,劣势是缺失了分支信息,好像从没存在过该分支一样.
- 将目标分支上的工作成果转移到到主干分支 : git rebase master
- 主干分支接收已转移好的目标分支工作成果 : git rebase <branch>