Git 工作流的一些經驗分享

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

什么是Git工作流？

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

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

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

集中式工作流

集中式工作流 | center

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

功能開發工作流

功能開發工作流

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

Gitflow工作流

Gitflow工作流

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

Forking工作流

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://www.jianshu.com/p/ca5ee4ea6420