Git 工作流的一些經驗分享

筆者使用Git有一段時間了，踩過不少坑，這裡分享下我在git工作流方面的一些經驗。

什麼是Git工作流？

Git工作流你可以理解為工作中團隊成員遵守的一種程式碼管理方案，在Git中有以下幾種工作流方案作為方案指導：

• 集中式工作流
• 功能開發工作流
• Gitflow工作流
• Forking工作流

下面針對性說下每個工作流可能使用到的場景和適用性：

集中式工作流

集中式工作流 | center

這種工作方式跟svn類似，它只有一個master分支，開發者會先把遠端的倉庫克隆到本地，之後的修改和提交都在本地操作，直到在某個合適的時間點將本地的程式碼合入到遠端master。這種工作流比較適合小團隊，因為小團隊可能不會太多的協作和合流的動作。

功能開發工作流

這種工作流關注功能開發，不直接往master提交程式碼保證它是穩定並且乾淨的，而是從master拉取feature分支進行功能開發，團隊成員根據分工拉取不同的功能分支來進行不同的功能開發，這樣就可以完全隔離開每個人的工作。當功能開發完成後，會向master分支發起Pull Request，只有稽核通過的程式碼才真正允許合入master，這樣就加強了團隊成員之間的程式碼交流，也就是我們常說的Code Review。

Gitflow工作流

這個工作流其實也是我們團隊採用的工作流，這也是很多團隊會採用的工作流，它會相對複雜一點，但它非常適合用來管理大型專案的釋出和維護，後面筆者也會詳細講下這一塊。貫穿整個開發週期，master和develop分支是一直存在的，master分支可以被視為穩定的分支，而develop分支是相對穩定的分支，特性開發會在feature分支上進行，釋出會在release分支上進行，而bug修復則會在hotfix分支上進行。筆者也是花了不少時間才熟練掌握整個工作流，期間遇到不少坑，後面會跟大家分享下。

Forking工作流

Forking工作流對於開源專案貢獻者一定不陌生了，它有一個公開的中央倉庫，其他貢獻者可以Fork（克隆）這個倉庫作為你自己的私有倉庫，開源專案維護者可以直接往中央倉庫push程式碼，而程式碼貢獻者只能將程式碼push到自己的私有倉庫，只有專案維護者接受程式碼貢獻者往中央倉庫發起的pull request才會真正合入。

小結一下

上面已經大致講了在git當中的四種比較常見的工作流，都是需要開發者去實踐理解的。

關於git工作流，只有選用最合適自己團隊的工作流才能有效的提高開發效率，上面提到的一些工作流模式都有各自的適用場景，如何選用適合自己團隊的工作流得結合團隊成員的實際情況，看團隊成員對於工作流的理解程度，還有對於工作流的執行程度。

我們團隊的一些實踐

現在講下我們團隊針對Gitflow的一些實踐：

master分支

• 主分支
• 保持穩定
• 不允許直接往這個分支提交程式碼，只允許往這個分支發起merge request
• 只允許release分支和hotfix分支進行合流

develop分支

• 開發分支
• 相對穩定的分支
• 用於日常開發，包括程式碼優化、功能性開發

feature分支

• 特性分支
• 從develop分支拉取，用於下個迭代版本的功能特性開發
• 功能開發完畢合併到develop分支

release分支

• 釋出分支
• 從develop分支拉取
• 用於迴歸測試，bug修復
• 釋出完成後打tag併合入master和develop

hotfix分支

• 熱更新分支
• 從develop分支拉取
• 用於緊急修復上線版本的問題
• 修復後打tag併合入master和develop

大家可能會發現我們這個跟標準的Gitflow工作流有些差別，其實也沒有什麼標準不標準的，前面說到要結合團隊的實際情況，我們團隊對於目前所採用的工作方式都是達成共識的，所以有一些差異並沒有關係。

說了這麼久，還沒有一句git命令，那就讓大家感受一下吧（感謝Bugly小色熊整理）：

1). 首先將遠端程式碼拉取到本地

    git clone xxx
    git checkout -b develop origin/develop

2).新建feature分支

    git checkout -b feature 

3).多人在feature上開發，如果中途需要將develop的變更合入feature，所有人需要將本地的程式碼變更提交到遠端

    git fetch origin 
    git rebase origin/feature
    git push origin feature

然後由feature負責人rebase develop分支，刪除原來feature分支，重新新建feature分支；

    git fetch origin
    git rebase origin/feature
    git rebase develop
    git push origin :feature
    git push origin feature

這樣可以保證feature保持線性變更；

4).feature開發完成後，所有人需要將本地的程式碼變更提交到遠端

    git fetch origin 
    git rebase origin/feature
    git push origin feature

然後由feature負責人rebase develop分支，然後將feature分支合入develop，刪除feature；

    git fetch origin
    git rebase origin/feature
    git rebase develop
    git checkout develop
    git merge feature
    git push origin :feature

這樣可以保證develop保持線性變更，各feature的變更完整可追溯；
5).合入feature後拉出對應的release/feature分支，後續bug修復在release/feature上

    git checkout develop
    git checkout -b release/feature

release/feature分支的同步合併與feature分支相同
6).release/feature分支bug修復完成後，拉取對應的tag推送遠端進行釋出

    git tag -a v1.0 -m 'feature釋出'
    git push origin v1.0

之後將release/feature合入develop分支，然後刪除

    git rebase develop
    git checkout develop
    git merge release/feature
    git push origin :release/feature

7).釋出完成後將release合入master分支，保證master為最新穩定版本（實際操作為發起merge request）

總結

本篇文章主要針對筆者工作中對於git工作流的一些理解和實踐，目前我們團隊也是嚴格按照這樣的工作流來完成日常的開發工作，一個讓團隊成員認可並且有效的工作流才是最適合我們的工作流，任何規則不是為了限制我們思考，而是為了讓工作更加高效有序，儘量減少人為的失誤。git是一個博大精深的東西，筆者也是不斷在實際應用中去理解它，任何一門技術的學習也是這樣，就像程式設計師常用來裝逼的一首詩：

紙上得來終覺淺，絕知此事要躬行。

參考資料：http://blog.jobbole.com/76847/