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 分支上共享他們的代碼。

<strong>流程

這裡的流程是這樣的：

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

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

<strong>焦油坑

這裡有幾個坑需要注意：

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

<strong>總結：

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

功能分支協同工作流

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

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

<strong>流程：

這裡的流程是這樣的：

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. 刪除分支[可選<strong>步驟]：這裡有點閱後即焚的感覺(git branch -d jackyfei_dev)，當然你不刪除也無妨，後續可以繼續使用。

切割分支：

合併分支：

推送分支：

<strong>注意事項

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

<strong>焦油坑

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

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

<strong> 總結：

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

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

GitFlow協同工作流

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

<strong>流程

這裡的流程是這樣的：

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

<strong> 主要事項

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

<strong> 焦油坑

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

GitHub Flow

<strong>流程

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

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

<strong>焦油坑

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

GitLab Flow

<strong>流程

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

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

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

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

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

總結

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

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

閱讀更多 IT人張飛洪 的文章

關鍵字: 協同工作 IDE 工作這一年