GIT merge 和 rebase

今天新拍了個自拍照，先來炫耀一下，給各位大佬養養眼，接下來好認真的學習知識啊 😁

忽然想起了這個知識仍是由於最近剛學會使用sourTree，哈哈哈，不要嘲笑我，我以前只用git命令，學了這個才知道不打命令是多麼的好，🤡，因此忽然來回顧了一下這個問題老生常談可是怕本身忘記了，仍是記錄一下，merge和rebase (￣▽￣)

1.git merge

我的以爲這個圖仍是挺有表明性的，主分支develop，在這個分支上我切出了本身的分支，就叫feature吧，簡單來理解，就是本身在本身的feateure上提交了一些東西，這個時候，你的隊友在主分支上也提交了一些東西，這個時候就會出現兩個commit，主分支會新有一個commit來把子分支上的兩個commit合併。這時候提交的形狀就不是一條直線。

git rebase

rebase會把你當前分支的 commit 放到公共分支的最後面,因此叫變基。就好像你從公共分支又從新拉出來這個分支同樣。你如今從主分支master拉一個feature分支出來，主分支又提交，當你開發完commit時，就會就會把你當前的幾個 commit，放到那我的 commit 的後面。

變基/衍合，rebase，對指定的base自己並無什麼影響；只是重寫base以後的commit歷史。

merge V.S. rebase

何時用merge；基於上述不一樣的merge行爲（fast-forward，--no-ff，squash），什麼場景下用哪一種merge：

merge執行一個合併，這個合併應該反應業務層面的合併，而非技術行爲。咱們但願在當前分支上往前走，這樣它就包含了其餘分支的工做。

因此問題的關鍵是：這個「其餘分支」是什麼樣的分支？這個「其餘分支」須要在歷史圖譜中展現麼？

本地的、臨時的分支，使用它僅僅是爲了使master保持clean。

1.若拉出本地分支後，master往前走了，此時在本地分支：

git rebase -i master
複製代碼

將本地分支變基到最新的master節點（從新梳理本地歷史提交信息好比合併成一個commit），好似本地分支就是在最新的master節點上作的開發工做，以保證合併到master後呈現線性增加。

2.在master上：

git merge (fast-forward)
複製代碼

最終以一個或幾個commit展示在master上。

知名分支，團隊明肯定義的，多是用來追蹤bug/feature。

永遠不要用rebase，而是用

git merge --no-ff
複製代碼

以保留清晰完整的歷史圖譜。