導讀Git相關的文章和教程非常多，但是系統介紹和了解工作流的人并不多，在使用過程中用錯或用偏的也不少，這里分享的是，假設你已經入門的情況下，我們如何去選擇適合團....

Git相關的文章和教程非常多，但是系統介紹和了解工作流的人并不多，在使用過程中用錯或用偏的也不少，這里分享的是，假設你已經入門的情況下，我們如何去選擇適合團隊需要的工作流。git優勢

這里先嘮叨git的優勢，對比傳統的代碼管理工具，git至少有以下這些優點：

• 有溫度的工具：由 Git 衍生出來的 github/GitLab 可以幫你很好地管理編程工作，比如 wiki、fork、pull request、issue……集成了與編程相關的工作，讓我們的工作可以呈現在一個工作平臺上，并以此來規范整個團隊的工作。
• 分布式管理：你可以離線提交代碼，而不用擔心網絡問題。
• 合并分支管理：合并分支后也能查看整個代碼的變更記錄
• 分支快速切換：Git 切換分支的時候通常很快，不像其他版本管理器，比如SVN，每個分支一份拷貝。

git常用命令

跳轉這里查看常用命令：常用命令

這里記錄自己平時經常使用的一些命令，并不是本文的重點。另外叨叨一下，有些人喜歡在集成的IDE下通過界面方式來進行操作，比如vs code或者eclipse都有傻瓜化的集成，這里推薦使用命令行操作，我覺得有如下一些優勢:

• 第一、可以和IDE解耦，不用換一個IDE就要去了解對應界面的使用方法；
• 第二、命令行的操作非常快速，當然缺點是你需要記憶一些命令，但是常用的命令真心不多；
• 第三、命令行擁有界面沒有的體驗，比如一個簡單的git status你可以查看內部更多的詳情；git stash命令，可以把當前沒有完成的事先暫存一下，然后去忙別的事；git cherry-pick命令可以讓你有選擇地合并提交。git add -p可以讓你挑選改動提交。

git工作流介紹

市面上有以下幾種常見的工作流：

• 中心式協同工作流
• 功能分支協同工作流
• github協同工作流
• gitlab協同工作流
• gitflow協同工作流

這里把gitflow工作流放在最后面，是因為實際體驗很糟糕，不知道你有沒有感受，初次見過gitflow的工作流，覺得非常復雜，不自覺的對git的使用產生抵觸心理，至少我的感受很深。

中心式協同工作流

這種方式等于把git當做svn適用，很多同學估計都是這么用的。這種協同方式是所有的人都在 Master 分支上共享他們的代碼。

流程

這里的流程是這樣的：

• 從服務器上把代碼同步下來；
• 本地編碼后，再add/commit到本地倉庫
• 最后再push到origin master上

這里的第三步有可能出錯，因為可能別人在你之前在相同地方已經提交了代碼，這時候你需要先(git pull --rebase)一下，如果發現沖突，就解決沖突然后繼續合并(git rebase --continue)。到這里你是否感覺和svn越來越像，每天早上過來定時的update一下，然后再編碼，上傳代碼之前也是這樣先update一下，再做上傳操作？

焦油坑

這里有幾個坑需要注意：

• 代碼沖突：建議每天編碼之前和代碼上傳之前不定期、頻繁的進行git pull --rebase。
• 代碼干擾：隨著開發團隊規模的擴大，可能你pull一個不可運行的代碼下來(push上去的人沒有用心檢查是否可以編譯通過)，這時候你的麻煩開始產生了，你要停下手上的活，花費可能很久的時間去把代碼編譯通過，于是我們經常聽到很多開發人員在那邊互相抱怨，怎么就不能好好檢查后再上傳呢，還讓不讓人寫代碼，好好學習一下svn怎么用吧……

總結：

中心式的協同顯然無法滿足團隊規模的擴展和代碼的干擾沖突，而且產品上線后，master的BUG會直接影響生產環境，也就說master其實是不穩定的，而用不穩定的主干直接和生產環境掛鉤，后果可想而知。所以該流程不適用產品線迭代開發和持續更新，如果你只有1-2個開發人員那就罷了，否則一般不建議使用這種方式，接下來就要介紹如何去避免上面的這些焦油坑，也就是我們的功能分支協同工作流上場了。

功能分支協同工作流

上面的那種方式有一個問題，就是大家都在一個主干上開發程序，對于小團隊或是小項目你可以這么干，但是對比較大的項目或是人比較多的團隊，這么干就會有很多問題。最大的問題就是代碼可能干擾太嚴重。尤其是，我們想安安靜靜地開發一個功能時，我們想把各個功能的代碼變動隔離開來，同時各個功能又會有多個開發人員在開發。

這時，我們不想讓各個功能的開發人員都在 Master 分支上共享他們的代碼。我們想要的協同方式是這樣的：同時開發一個功能的開發人員可以分享各自的代碼，但是不會把代碼分享給開發其他功能的開發人員，直到整個功能開發完畢后，才會分享給其他的開發人員（也就是進入主干分支），接下來就是我們的功能分支上場了。

流程：

這里的流程是這樣的：

1. 切割開發分支：從git服務器上clone一份代碼下來，并在本地切割出一個分支(git checkout -b jackyfei_dev)；
2. 編碼提交：在分支下進行本地編碼，后進行git add和git commit;
3. 合并分支：切換到master分支(git checkout master)，合并jackyfei_dev分支(git merge jackyfei_dev)；
4. 推送到服務器：最后push到服務器(git push -u origin master)，注意這里推送后不會把分支一起推送到服務器，如果要推送分支上去可以使用命令：git push origin jackyfei_dev；
5. 代碼重審或代碼測試[可選步驟]：代碼審查人員或代碼測試人員在你的分支上審查或測試通過后，在服務器端進行合并操作。該步驟根據團隊大小進行選擇，非必做項。
6. 刪除分支[可選步驟]：這里有點閱后即焚的感覺(git branch -d jackyfei_dev)，當然你不刪除也無妨，后續可以繼續使用。

切割分支：

合并分支：

推送分支：

注意事項

• 刪除分支：如果你在還沒合并分支的時候，就要進行分支刪除操作，git會有一個提示不能刪除的操作，如果有重要的代碼沒有合并，建議不要-D強制刪除。
• 分支沖突：在合并的過程會出現沖突，如下圖所示，這時候需要手動解決沖突，方式和svn一樣。手動合并后，再git add/git commit就可以了。
• 版本同步：這里的master和線上的版本保持同步，所以master必須盡量保證是干凈的，穩定的，一般不要輕易去動他。

焦油坑

這里和注意事項不同，羅列的是該協作方式的缺陷：

• 線上出現BUG，本地分支正開發到一半，還沒經過測試，無法進行發布，這時該如何解決？
• master無法保證一定是純凈的，因為每個人都可以merge上去

總結：

我們可以看到，其實，這種開發也是以服務器為中心的開發，還不是 Git 分布式開發，它只不過是用分支來完成代碼改動的隔離。這里隔離的內容不叫項目而是小功能，這符合了產品快速迭代的需求。

如果團隊規模不大，采用這種分支協同反而可能增加不必要的工作，所以要根據團隊規模和現實當中的問題進行選型，一般團隊超過兩個人以上，而且線上環境頻繁變更導致經常性的出現不穩定的異常，這種協同方式還是挺不錯的。這里要思考的是，如果線上出了問題，本地開發一半無法進行發布的問題該如何處理呢？

GitFlow協同工作流

針對功能分支工作流的不足，GitFlow出現了，該工作流總共有5個分支，而其中的master和developer兩個分支需要長期維護，其他的分支都是可以隨時“閱后即焚”的。

流程

這里的流程是這樣的：

1. Feature 分支：也就是功能分支，用于開發功能，其對應的是開發環境，可以“閱后即焚”。
2. Developer 分支：是開發分支，一旦功能開發完成，就向Developer 分支合并，合并完成后，刪除功能分支。這個分支對應的是集成測試環境。
3. Release 分支：當 Developer 分支測試達到可以發布狀態時，開出一個 Release 分支來，然后做發布前的準備工作。這個分支對應的是預發環境。之所以需要這個 Release 分支，是我們的開發可以繼續向前，不會因為要發布而被 block 住而不能提交。一旦 Release 分支上的代碼達到可以上線的狀態，那么需要把 Release 分支向 Master 分支和 Developer 分支同時合并，以保證代碼的一致性。然后再把 Release 分支刪除掉。
4. Hotfix 分支：是用于處理生產線上代碼的 Bug-fix，每個線上代碼的 Bug-fix 都需要開一個 Hotfix 分支，完成后，向 Developer 分支和 Master 分支上合并。合并完成后，刪除 Hotfix 分支。
5. Master 分支：也就是主干分支，用作發布環境，上面的每一次提交都是可以發布到線上環境的。

主要事項

• 我們需要長期維護 Master 和 Developer 兩個分支。
• Release 和 Hotfix 分支需要同時向兩個分支作合并。所以，如果沒有一個好的工具來支撐的話，這會因為我們可能會忘了做一些操作而導致代碼不一致。
• GitFlow 協同雖然工作流比較重。但是它幾乎可以應對所有公司的各種開發流程，包括瀑布模型，或是快速迭代模型。

焦油坑

• 分支太多，所以會出現 git log 混亂的局面。
• 在開發得足夠快的時候，你會覺得同時維護 Master 和 Developer 兩個分支是很太無聊，因為大部分情況下兩者都是一樣的。
• 管理變得非常復雜。尤其當你想回滾某些人的提交時，你就會發現這事似乎有點兒不好干了。
• 工作過程中，你會來來回回地切換工作的分支，有時候一不小心沒有切換，就提交到了不正確的分支上，你還要回滾和重新提交等等。

GitHub Flow

流程

除非你是開源項目或者有購買github企業版，否則一般企業不會把核心代碼托管在公共的github上面。

• 開發人員都把github上的代碼 fork 到自己的代碼倉庫中。
• 開發容易代碼庫有兩個遠程倉庫，一個是自己fork的庫，一個是官方的庫。
• 開發人員在本地建“功能分支”，在這個分支上做代碼開發。
• 開發完成后，功能分支被 push 到開發人員自己的代碼倉庫中。
• 然后，向“官方庫”發起 pull request，并做 Code Review。
• 一旦通過，就向官方庫進行合并。

焦油坑

• GitHub Flow 這種玩法雖然變得很簡單，但是沒能把我們的代碼和運行環境給聯系在一起。

GitLab Flow

流程

以上是引入環境分支流程：

• 從master分支拉取一個預發布環境分支
• 從預發布環境分支拉取一個生產環境分支

流程雖然簡單，但是增加分支后都是工作量，如果有很好的引入CI/CD，其實這一步也是多余的。以上主要是針對2C的互聯網業務，2B的要看情況來處理，實時性沒有那么強。

以上是引入版本分支流程：

對于版本和代碼分支的問題，我覺得這應該是有意義的，但是，最好不要維護太多的版本，版本應該是短暫的，等新的版本發布時，老的版本就應該刪除掉了。

總結

總之，GitFlow大而全，但是很重；中心式協同流簡單但擴展性不好；功能分支和GitHub協同流輕量靈活(無須關注環境和多版本)，適應性強大(既能適應快速開發和迭代，也適應CI/CD)，個人傾向使用這功能分支協同工作流。當然沒有一招鮮吃遍天的銀彈，具體選擇什么協作流程還是要具體分析，比如GitFlow的這種流程，可以考慮把Release分支裁剪掉，保證輕量化的同時，也能滿足實際流程的需要；中心式的流程增加版本分支，也能很好的管理產品的版本代碼。

當我們把精力放在軟件架構和開發流程優化上，我們的git協同流會變得更加簡單，所以與其熟練玩弄git協同流，不如放心思放在架構和開發流程的優化上，這才有事倍功半的效果。最后附上對比圖，供你選擇和參考，如果你們的團隊有更好的用法，請多賜教。