其實git的官網對變基的解析挺詳細的了:位址
從原理上也能理解【變基】和【合併】有啥區別。
我的理解是,【變基】和【合併】都能解決乙個問題,那就是合併**。但是他們的區別是:在master的記錄上會有所不同。如下圖:(我是用sourcetree做的合併與變基的)
【合併】
【變基】
從上面那兩個圖可以看到,如果是【合併】的話,c4
這乙個記錄其實還是在experiment
分支上的,也就是說master
分支上並沒有c4
的提交記錄。
但如果是【變基】,c4
的記錄也會出現在master
上
而且在這分支關係圖上還可以看到,【變基】和【合併】對**的處理的差異。
【合併】是以c2
為基準點,把c3
和c4
合併,並生成新的提交。
而【變基】是以c3
為基準點,並且把分支上的變動(也就是c4
這一次提交的變動)再在c3
上重演一遍,所以master
也能有c4
的記錄了。
於是單純看master
的提交記錄就可以知道
【合併】是沒有c4
的提交記錄的
【變基】是有c4
的提交記錄的
應用場景就因人而異了,有些人喜歡知道分支的所有改動(所有提交),所以就會用【變基】,把分支的所有記錄移動到master上
但是我個人還是比較喜歡合併,因為我們都是按照功能進行分支開發的,所以我看到你合併了這個分支我就知道你完成了這個功能的開發,不需要知道你到底做了什麼東西。而當我真的要知道你提交了什麼改動了什麼,我直接切去你的開發分支不就好了嗎
以上當屬個人見解,當然【變基】還有很多妙用,不僅僅是修整歷史,將分支歷史併入主線。
這麼簡單。
Git中rebase的作用
git rebase,顧名思義,就是重新定義 re 起點 base 的作用,即重新定義分支的版本庫狀態。要搞清楚這個東西,要先看看版本庫狀態切換的兩種情況 我們知道,在某個分支上,我們可以通過git reset,實現將當前分支切換到本分支以前的任何乙個版本狀態,即所謂的 回溯 即實現了本分支的 後悔...
git中merge和rebase的區別
最開始實習的時候是使用svn,之後正式工作就一直在使用git,這樣算起來,使用git也有兩年的時間了。以前帶我的同事,讓我在拉 的時候要我使用git pull rebase,一直很納悶為什麼要那樣做,後來遇到拉 的時候有許多衝突要解決,然後去查詢資料,才了解到其中的一些事情。今天分享一下,順便自己也...
Git分支merge和rebase的區別
git merge是用來合併兩個分支的。git merge b 將b分支合併到當前分支 同樣 git rebase b,也是把 b分支合併到當前分支 原理 如下 假設你現在基於遠端分支 origin 建立乙個叫 mywork 的分支。git checkout b mywork origin 假設遠端...