git 鼓勵大量使用分支---"早建分支!多用分支!",這是因為即便創建再多的分支也不會造成存儲或內存開銷,並且分支的作用有助於我們分解邏輯工作,這樣一樣其實比維護單一臃腫分支要簡單得多!
正因如此,每個新功能會創建合併分支,修復 bug 會創建合併分支等等,一段時間後再次回顧整個版本庫的提交歷史就會發現分支錯綜複雜,難以理清!
雖然"條條大路通羅馬",但錯綜複雜的道路容易讓人迷失方向,如果不使用分支,當然就不存在"分叉問題",所以在某些情況下我們希望尋求一種替代方案來解決分支合併帶來的"分叉問題"!
回顧提交歷史
查看提交歷史: git log --pretty=oneline --graph --abbrev-commit
僅僅是簡單的演示項目的提交歷史都已經出現"分叉問題",更何況真實的企業級開發項目呢?如果真的是多分支多人合作開發的話,"分叉現象"將更加明顯,模擬效果圖大概長這樣:
git-branch-multiple.png
整理提交歷史
如果想要一條直路直達羅馬,那我們必須規劃好路徑,摒棄小道,堅持主幹道.git的各種 dev,feature等分支就是需要治理的一條條分叉小道,而 master 主分支就是我們的大道.
演示項目有三個分支,主幹master,開發dev,自定義snow,目標是將自定義 snow 分支的工作成功整理合併到主幹分支,從而解決"分叉問題",dev 分支與項目演示無關,無需更改.
(1). 切換到 snow 分支並提交一個版本(learn git rebase)
git-branch-rebase-snow.png
(2). 切換到 master 分支也提交一個版本(modify README)
git-branch-rebase-master.png
(3). 切換回 snow 分支,整理提交歷史(git rebase)到 master 分支
git-branch-rebase.png
(4). 切換回 master 主幹分支再次變基合併 snow 分支
git-branch-rebase-back-master.png
(5). 整理分支完成,最終主幹分支是一條直線
這一次我們沒有使用 git merge 而是採用 git rebase 方式完成了分支的合併,優點是提交歷史更清晰,缺點是丟失了分支信息.
小結
git rebase 變基合併分支,實際上就是取出一系列的提交版本並“複製”到目標版本,從而形成一條新的提交歷史線.
比如我們想要把 bugFix 分支裡的工作直接移到 master 分支上,移動以後會使得兩個分支的功能看起來像是按順序開發,但實際上它們是並行開發的,這就是 git rebase 的作用.
git rebase 的優勢是創造更線性的提交歷史,使得代碼庫的提交歷史變得異常清晰,劣勢是缺失了分支信息,好像從沒存在過該分支一樣.
- 將目標分支上的工作成果轉移到到主幹分支 : git rebase master
- 主幹分支接收已轉移好的目標分支工作成果 : git rebase <branch>
閱讀更多 雪之夢技術驛站 的文章
