現(xiàn)在普遍流行的git規(guī)范是GitFlow，但是最近又看到一個新的Git規(guī)范，感覺這個新的規(guī)范，設(shè)計更加合理，并且可以解決
GitFlow在項目運(yùn)用中存在的問題，本文羅列了這兩種規(guī)范的主要內(nèi)容，并做了對比。
Git并行規(guī)范
分支流轉(zhuǎn)規(guī)范
發(fā)布分支：該分支從 預(yù)發(fā)布分支 合并而來；如果沒有 預(yù)發(fā)布分支，則從 測試分支 合并而來；在將分支（如：預(yù)發(fā)布分支 或 測試分支）合并到發(fā)布分支前，需要確保 該分支 已經(jīng)包含了發(fā)布分支上的所有版本；如果沒有包含發(fā)布分支上的所有版本，則取消本次的分支流轉(zhuǎn)，并重新轉(zhuǎn)測 或 從 原始分支 重新發(fā)起流轉(zhuǎn)；
預(yù)發(fā)布分支：該分支從 測試分支 合并而來；如果不需要，也可以不設(shè) 預(yù)發(fā)布 分支；
測試分支：該分支從 被轉(zhuǎn)測的分支 合并而來；如：功能、修復(fù)、協(xié)作、合并；在轉(zhuǎn)測前，需要確保 被轉(zhuǎn)測的分支 已經(jīng)包含了發(fā)布分支上的所有版本；即：如果被轉(zhuǎn)測的分支在轉(zhuǎn)測前，發(fā)布分支上有新的版本發(fā)布，且這些新的版本并沒有包含在 被轉(zhuǎn)測的分支上，則需要先把發(fā)布分支上那些新的版本合并到被轉(zhuǎn)測分支，然后才能轉(zhuǎn)測，即：將被轉(zhuǎn)測分支合并到測試分支上；
合并分支：該分支是對 需要合并的多個分支 進(jìn)行合并而來的分支；
功能分支：基于 發(fā)布 分支創(chuàng)建；
修復(fù)分支：在沒有不需要與被修復(fù)的問題一起轉(zhuǎn)測的代碼的情況下，應(yīng)該在 問題所在的 流轉(zhuǎn)鏈 中的 原始分支 上直接修復(fù)問題，不必創(chuàng)建單獨(dú)的修復(fù)分支（這是為了保證原始分支的完整性）；如果 問題 所在的 流轉(zhuǎn)鏈 中的 原始分支 不存在 或者 原始分支 中包含了不能與被修復(fù)的問題一起轉(zhuǎn)測的代碼，則應(yīng)該 基于 問題所在的 流轉(zhuǎn)鏈 中的 終點(diǎn)分支 創(chuàng)建 修復(fù)分支，然后在該 修復(fù)分支 上修修復(fù)問題（這是為了保證 多個任務(wù)或多個功能 之間 互不干擾）；當(dāng)問題被修復(fù)完問題后，再將該 修復(fù)分支 合并到 其對應(yīng)的專門用于測試該修復(fù)問題的測試分支中，不應(yīng)該把 修復(fù)分支 合并到 該修復(fù)分支的 母分支 或者 母分支 對應(yīng)的 測試分支 中；即：每個修復(fù)分支 都有其對應(yīng)的、專門的測試分支 （這是為了保證 測試分支 和 對應(yīng)的 被轉(zhuǎn)測分支 的代碼的一致性，多個任務(wù) 或 多個功能之間 獨(dú)立、互不干擾）；
比如：
如果，被修復(fù)的問題是由 功能A 導(dǎo)致的，且 功能A分支 上不包含不能與被修復(fù)的問題一起轉(zhuǎn)測的代碼，則應(yīng)該直接在 功能A分支 中修復(fù)問題，不用創(chuàng)建專門的 修復(fù)分支；
如果 功能A 分支 已經(jīng)被刪除了 或者 包含不能和 被修復(fù)的問題 一塊轉(zhuǎn)測的代碼，則應(yīng)該基于 被修復(fù)問題所在的 流轉(zhuǎn)鏈 的 終點(diǎn)分支 創(chuàng)建 專門用于修復(fù)該問題的 修復(fù)分支；問題被修復(fù)完后，再將該修復(fù)分支 合并到 專門用于測試該問題的 測試分支 中；臨時分支：被合并到發(fā)布分支（即正式發(fā)布之后）才可以被刪除；建義正式發(fā)布運(yùn)行一段時間之后再刪除；如果不必要，也不建義永久留著，以便倉庫保持整潔；
每個 預(yù)發(fā)布分支 都有其唯一對應(yīng)的 測試分支，每個 測試分支 都有其唯一對應(yīng)的 被轉(zhuǎn)測分支；即：每個 被轉(zhuǎn)測分支 都有其 單獨(dú)對應(yīng)的 測試分支，每個 測試分支 都有其 單獨(dú)對應(yīng)的 預(yù)發(fā)布分支；（這是為了保證對應(yīng)的 預(yù)發(fā)布分支、測試分支、被轉(zhuǎn)測分支 的代碼的一致性，多個任務(wù) 或 多個功能之間 獨(dú)立、互不干擾）。
示例圖如下：
GitFlow規(guī)范
git常用分支
Production 分支 ： 也就是我們經(jīng)常使用的Master分支，這個分支最近發(fā)布到生產(chǎn)環(huán)境的代碼，最近發(fā)布的Release， 這個分支只能從其他分支合并，不能在這個分支直接修改。
Develop 分支：這個分支是我們是我們的主開發(fā)分支，包含所有要發(fā)布到下一個Release的代碼，這個主要合并與其他分支，比如Feature分支。
Feature 分支：這個分支主要是用來開發(fā)一個新的功能，一旦開發(fā)完成，我們合并回Develop分支進(jìn)入下一個Release。
Release 分支：當(dāng)你需要一個發(fā)布一個新Release的時候，我們基于Develop分支創(chuàng)建一個Release分支，完成Release后，我們合并到Master和Develop分支。
Hotfix 分支：當(dāng)我們在Production發(fā)現(xiàn)新的Bug時候，我們需要創(chuàng)建一個Hotfix, 完成Hotfix后，我們合并回Master和Develop分支，所以Hotfix的改動會進(jìn)入下一個Release。
示例圖如下：
對比
GitFlow的問題：
- 需要同時維護(hù)兩個分支，會存在代碼不同步的可能性
(master,develop);
假如已經(jīng)上線的項目發(fā)現(xiàn)了bug，需要及時修復(fù)，GitFlow的規(guī)范是在Hotfix分支進(jìn)行修改，修改以后，要分別合并到master和develop分支，這樣才能保證master和develop的代碼同步，因為這兩個分支都是長期維護(hù)的分支。如果我們哪一次忘記了同步，項目可能會出現(xiàn)問題。
- 其他功能的開發(fā)，包含其他未開發(fā)完成的功能的代碼；
假如多個功能在不同的時間，并行進(jìn)行開發(fā)，后面功能分支會包含之前功能分支的代碼，因為他們都是基于develop分支創(chuàng)建的，如果之前的功能存在bug，這個可能會影響后面功能的開發(fā)。
- 上線的功能，可能包含未上線功能的代碼；
這個問題也是由于第2個問題導(dǎo)致的，多個功能并行開發(fā)，如果前面的部分功能臨時決定暫不上線，先上線后面開發(fā)的功能，那上線的功能會包含前面暫時不上線的功能的代碼。
而
Git并行規(guī)范不存在這樣的問題。因為它只有一個長期的產(chǎn)品分支，一個新的功能，都是基于這個產(chǎn)品分支而創(chuàng)建的，每一個功能在沒有測試完成之前是不會合并到產(chǎn)品分支的，這樣不管你有多少并行的開發(fā)分支，都是互不影響的。
