git merge和git rebase的區別, 切記：永遠用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的好處吧。

Git是一個免費的開源的分散式版本控制系統，具有儲存空間小、暫存區域便捷和多個工作流同時工作等特點。Git的功能雖然強大，但如果不按照規範的流程進行操作的話，很容易使得提交歷史混亂，甚至程式碼衝突，而git-flow工程流程就是一種規範。

git-flow 並不是要替代 Git，它僅僅是將標準的 Git 命令用指令碼組合了起來。

1、擁有2個長期分支

主分支master和開發分支develop。master 只能用來包含穩定產品程式碼，你不能直接提交程式碼到 master 分支上；develop 是進行任何新的功能開發的基礎分支，功能開發完後，程式碼將合併到develop分支，並且等待被整合到 master 分支中。

2、擁有3個短期分支

分別是功能分支（feature branch）、預釋出分支（release branch）和補丁分支（hotfix branch）。feature分支就是當前正在進行的功能點開發的分支；等所有的功能開發完並且合併到develop分支後，需要打一個release分支，表示即將要釋出了；等我們的產品上線後，如果發現有bug，此時需要建一個hotfix分支來進行修復。這幾個分支一旦完成開發，都會被合併進develop或者master分支，然後被刪除。

1、專案初始化

當在專案的根目錄執行 “git flow init” 命令時，你會看到有master、develop、feature、release、hotfix分支名稱。

2、開始新功能

產品妹子過來了，說我們要接入蘋果支付，OK，新建分支apple-pay，執行命令“git flow feature start apple-pay"。

3、完成新功能

戴上耳機，噼裡啪啦，1個小時候過後功能開發完了，完成該功能，執行命令“git flow feature finish apple-pay”。

4、準備預釋出

測試同學說，功能已經測試完了，沒有問題，準備釋出更新吧，執行命令“git flow release start V1.1.5”，這個地方最好帶上版本號。

5、完成預釋出

在步驟4的基礎上直接執行命令，“git flow release finish V1.1.5”。

6、發現bug

上線一個小時後，使用者反饋充值沒有到賬，立馬新建一個修復分支V1.1.5-fix，“git flow hotfix start V1.1.5-fix”，摘掉耳機，噼裡啪啦，10分鐘後，bug解決，測試驗證透過，完成修復分支，

“git flow hotfix finish V1.1.5-fix”。

git merge和git rebase的區別, 切記：永遠用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的好處吧。

Git是一個免費的開源的分散式版本控制系統，具有儲存空間小、暫存區域便捷和多個工作流同時工作等特點。Git的功能雖然強大，但如果不按照規範的流程進行操作的話，很容易使得提交歷史混亂，甚至程式碼衝突，而git-flow工程流程就是一種規範。

git-flow 並不是要替代 Git，它僅僅是將標準的 Git 命令用指令碼組合了起來。

1、擁有2個長期分支

主分支master和開發分支develop。master 只能用來包含穩定產品程式碼，你不能直接提交程式碼到 master 分支上；develop 是進行任何新的功能開發的基礎分支，功能開發完後，程式碼將合併到develop分支，並且等待被整合到 master 分支中。

2、擁有3個短期分支

分別是功能分支（feature branch）、預釋出分支（release branch）和補丁分支（hotfix branch）。feature分支就是當前正在進行的功能點開發的分支；等所有的功能開發完並且合併到develop分支後，需要打一個release分支，表示即將要釋出了；等我們的產品上線後，如果發現有bug，此時需要建一個hotfix分支來進行修復。這幾個分支一旦完成開發，都會被合併進develop或者master分支，然後被刪除。

1、專案初始化

當在專案的根目錄執行 “git flow init” 命令時，你會看到有master、develop、feature、release、hotfix分支名稱。

2、開始新功能

產品妹子過來了，說我們要接入蘋果支付，OK，新建分支apple-pay，執行命令“git flow feature start apple-pay"。

3、完成新功能

戴上耳機，噼裡啪啦，1個小時候過後功能開發完了，完成該功能，執行命令“git flow feature finish apple-pay”。

4、準備預釋出

測試同學說，功能已經測試完了，沒有問題，準備釋出更新吧，執行命令“git flow release start V1.1.5”，這個地方最好帶上版本號。

5、完成預釋出

在步驟4的基礎上直接執行命令，“git flow release finish V1.1.5”。

6、發現bug

上線一個小時後，使用者反饋充值沒有到賬，立馬新建一個修復分支V1.1.5-fix，“git flow hotfix start V1.1.5-fix”，摘掉耳機，噼裡啪啦，10分鐘後，bug解決，測試驗證透過，完成修復分支，

“git flow hotfix finish V1.1.5-fix”。