其實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 假設遠端...