一直以來對git的rebase和merge命令都有點混淆，剛好有朋友問到這一塊，所以也抽空去整理了下這方面内容，以作備忘！

git的merge和rebase都是用來合并分支的。

這裡不多解釋rebase命令，以及兩個命令的原理，下面主要說的是兩者在實際操作中的區别。

分支就是便于多人在同一項目中的協作開發。比方說：每個人開發不同的功能，在各自的分支開發過程中互不影響，完成後都提交到develop分支。極大的提高了開發的效率。

每個人創建一個分支進行開發，當開發完成，需要合并到develop分支的時候，就需要用到合并的命令。

合并的時候，有可能會産生沖突。

沖突的産生是因為在合并的時候，不同分支修改了相同的位置。所以在合并的時候git不知道那個到底是你想保留的，所以就提出疑問（沖突提醒）讓你自己手動選擇想要保留的内容，從而解決沖突。

1、采用merge和rebase後，git log的區别，merge命令不會保留merge的分支的commit：

2、處理沖突的方式：

• （一股腦）使用merge命令合并分支，解決完沖突，執行git add .和git commit -m'fix conflict'。這個時候會産生一個commit。
• （交互式）使用rebase命令合并分支，解決完沖突，執行git add .和git rebase --continue，不會産生額外的commit。這樣的好處是，‘幹淨’，分支上不會有無意義的解決分支的commit；壞處，如果合并的分支中存在多個commit，需要重複處理多次沖突。

3、git pull和git pull --rebase區别

git pull做了兩個操作分别是‘獲取’和合并。所以加了rebase就是以rebase的方式進行合并分支，默認為merge。

1、隻有在沖突的時候，解決完沖突才會自動産生一個commit。

如果想在沒有沖突的情況下也自動生成一個commit，記錄此次合并就可以用：git merge --no-ff命令，下面用一張圖來表示兩者的區别：

2、如果不加 --no-ff 則被合并的分支之前的commit都會被抹去，隻會保留一個解決沖突後的 merge commit。

我的理解：主要是看那個命令用的熟練，能夠有效的管理自己的代碼；還有就是團隊用的是那種方式。

我對于rebase比較熟悉，所以我一般都用rebase，但是現在的公司用的是merge --no-ff命令合并分支。所以，我在工作上就用merge，個人項目就用rebase。

也可以兩者結合：

• 獲取遠程項目中最新代碼時：git pull --rebase，這個時隐性的合并遠程分支的代碼不會産生而外的commit（但是如果存在沖突的commit太多就像上面說的，需要處理很多遍沖突）。
• 合并到分支的時候：git merge --no-ff，自動一個merge commit，便于管理（這看管理人員怎麼認為了）

其實看懂上面的兩幅圖就行了。注意兩點：commit log的區别和處理沖突的方式。

後面會分享更多devops和DBA方面的内容，感興趣的朋友可以關注一下~