作者：丁哥開講
鏈接：https://zhuanlan.zhihu.com/p/75499871
來源：知乎
著作權歸作者所有。商業轉載請聯繫作者獲得授權，非商業轉載請註明出處。
git merge和git rebase的區別, 切記：永遠用rebase
這一期來談一下git merge和git rebase的區別。
Git無疑現在已經成爲最流行的代碼管理工具之一。其中有兩個命令，對很多程序員造成了很多的困惑，一個是merge，一個是rebase。
這些困惑主要糾結於到底應該用merge還是用rebase。
在繼續深入探討之前，我先拋出我的觀點。如果你想擁有一套穩定的，健壯的代碼, 永遠要使用rebase。
不爲別的，就爲了rebase可以給你提供一套清晰的代碼歷史。
相反的, merge會給你一套亂七八糟的代碼歷史。當你看到這樣的代碼歷史的時候，我相信你絕對沒有心情去研究每一個歷史對應的代碼。
好，接下來我們就詳細分析一下這兩個命令的作用。假設我們的repo有這麼個主branch: master。
每個程序員在創建自己的代碼之前，要首先創建自己的個人分支，然後代碼修改開始。
假如你有6個程序員一起工作， 你就會有6個程序員的分支， 如果你使用merge, 你的代碼歷史樹就會有六個branch跟這個主的branch交織在一起。
那個畫風我相信對你一定很熟悉。想着那個畫風感覺到一切都好無助， 有個詞兒比較合適，叫做欲仙欲死。
這就是merge命令下生成的代碼分支歷史。
那麼rebase又能做到什麼程度呢？Rebase永遠不會導致多個歷史分支進行交織。它永遠都是一條線。純潔而又幹脆。輕輕爽爽的， 從不拖泥帶水。
那爲什麼會這樣呢？
先說一下merge。Merge命令會保留所有commit的歷史時間。每個人對代碼的提交是各式各樣的。儘管這些時間對於程序本身並沒有任何意義。但是merge的命令初衷就是爲了保留這些時間不被修改。這樣也就形成了以merge時間爲基準的網狀歷史結構。每個分支上都會繼續保留各自的代碼記錄, 主分支上只保留merge的歷史記錄。子分支隨時都有可能被刪除。子分子刪除以後，你能夠看到的記錄也就是，merge某branch到某branch上了。這個歷史記錄描述基本上是沒有意義的。
還有一個比較有意思的是你不能，也不應該去修改這個歷史記錄描述。那是因爲這個merge記錄裏面，不僅僅包含你自己的代碼，也包含別人的代碼。到這裏你能想象有多亂吧？
再來說一下rebase, 這個命令會始終把你最新的修改放到最前頭。比如你對主branch進行rebase以後, 你的所有修改就會在主branch當前所有的修改之前。你會更有信心保證你的代碼運行暢通無阻。通過你自己的測試以後, 你就可以放心的把代碼合併到主的branch裏面了。
這裏值得一提的是，rebase通常是發生在自己的個人branch上的。它的基礎就是現有的主branch。這樣做的好處就是保證每個人的代碼都可以運行在當前最新的主branch的代碼上。
這裏再提一個比較有意思的現象。在我工作的這麼多公司之中，只有不多的幾家在使用rebase, 有相當數量的公司還在使用merge。經過觀察我發現, 凡是代碼管理混亂的項目， 或者整個項目組的做決定者不太清楚代碼整潔的重要性， 或者腦子有問題的， 他們都在使用merge。哈哈，我開玩笑呢。
不過， 我還是建議大家去親身體驗一下rebase的好處吧。
好了，這期就先說這些，這裏是丁哥開講，歡迎關注防止失聯。