筆者使用git有一段時間了，踩過不少坑堰燎，這里分享下我在git工作流方面的一些經(jīng)驗聚磺。
什么是Git工作流？
Git工作流你可以理解為工作中團隊成員遵守的一種代碼管理方案聂沙，在Git中有以下幾種工作流方案作為方案指導：
- 集中式工作流
- 功能開發(fā)工作流
- Gitflow工作流
- Forking工作流
下面針對性說下每個工作流可能使用到的場景和適用性：
集中式工作流
集中式工作流 | center
這種工作方式跟svn類似秆麸，它只有一個master分支，開發(fā)者會先把遠程的倉庫克隆到本地逐纬，之后的修改和提交都在本地操作，直到在某個合適的時間點將本地的代碼合入到遠程master削樊。這種工作流比較適合小團隊豁生，因為小團隊可能不會太多的協(xié)作和合流的動作兔毒。
功能開發(fā)工作流
這種工作流關(guān)注功能開發(fā)，不直接往master提交代碼保證它是穩(wěn)定并且干凈的甸箱，而是從master拉取feature分支進行功能開發(fā)育叁，團隊成員根據(jù)分工拉取不同的功能分支來進行不同的功能開發(fā)，這樣就可以完全隔離開每個人的工作芍殖。當功能開發(fā)完成后豪嗽，會向master分支發(fā)起Pull Request，只有審核通過的代碼才真正允許合入master豌骏，這樣就加強了團隊成員之間的代碼交流龟梦，也就是我們常說的Code Review。
Gitflow工作流
這個工作流其實也是我們團隊采用的工作流窃躲，這也是很多團隊會采用的工作流计贰，它會相對復雜一點，但它非常適合用來管理大型項目的發(fā)布和維護蒂窒，后面筆者也會詳細講下這一塊躁倒。貫穿整個開發(fā)周期，master和develop分支是一直存在的洒琢，master分支可以被視為穩(wěn)定的分支秧秉，而develop分支是相對穩(wěn)定的分支，特性開發(fā)會在feature分支上進行衰抑，發(fā)布會在release分支上進行象迎，而bug修復則會在hotfix分支上進行。筆者也是花了不少時間才熟練掌握整個工作流停士，期間遇到不少坑挖帘，后面會跟大家分享下。
Forking工作流
Forking工作流對于開源項目貢獻者一定不陌生了恋技，它有一個公開的中央倉庫拇舀，其他貢獻者可以Fork（克隆）這個倉庫作為你自己的私有倉庫蜻底，開源項目維護者可以直接往中央倉庫push代碼骄崩，而代碼貢獻者只能將代碼push到自己的私有倉庫，只有項目維護者接受代碼貢獻者往中央倉庫發(fā)起的pull request才會真正合入薄辅。
小結(jié)一下
上面已經(jīng)大致講了在git當中的四種比較常見的工作流要拂，都是需要開發(fā)者去實踐理解的。
關(guān)于git工作流站楚，只有選用最合適自己團隊的工作流才能有效的提高開發(fā)效率脱惰，上面提到的一些工作流模式都有各自的適用場景，如何選用適合自己團隊的工作流得結(jié)合團隊成員的實際情況窿春，看團隊成員對于工作流的理解程度拉一，還有對于工作流的執(zhí)行程度采盒。
我們團隊的一些實踐
現(xiàn)在講下我們團隊針對Gitflow的一些實踐：
master分支
- 主分支
- 保持穩(wěn)定
- 不允許直接往這個分支提交代碼，只允許往這個分支發(fā)起merge request
- 只允許release分支和hotfix分支進行合流
develop分支
- 開發(fā)分支
- 相對穩(wěn)定的分支
- 用于日常開發(fā)蔚润，包括代碼優(yōu)化磅氨、功能性開發(fā)
feature分支
- 特性分支
- 從develop分支拉取，用于下個迭代版本的功能特性開發(fā)
- 功能開發(fā)完畢合并到develop分支
release分支
- 發(fā)布分支
- 從develop分支拉取
- 用于回歸測試嫡纠，bug修復
- 發(fā)布完成后打tag并合入master和develop
hotfix分支
- 熱更新分支
- 從develop分支拉取
- 用于緊急修復上線版本的問題
- 修復后打tag并合入master和develop
大家可能會發(fā)現(xiàn)我們這個跟標準的Gitflow工作流有些差別烦租，其實也沒有什么標準不標準的，前面說到要結(jié)合團隊的實際情況除盏，我們團隊對于目前所采用的工作方式都是達成共識的叉橱，所以有一些差異并沒有關(guān)系。
說了這么久痴颊，還沒有一句git命令赏迟，那就讓大家感受一下吧（感謝Bugly小色熊整理）：
1). 首先將遠程代碼拉取到本地
git clone xxx
git checkout -b develop origin/develop
2).新建feature分支
git checkout -b feature
3).多人在feature上開發(fā)，如果中途需要將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開發(fā)完成后，所有人需要將本地的代碼變更提交到遠程
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后拉出對應(yīng)的release/feature分支，后續(xù)bug修復在release/feature上
git checkout develop
git checkout -b release/feature
release/feature分支的同步合并與feature分支相同
6).release/feature分支bug修復完成后刺下，拉取對應(yīng)的tag推送遠程進行發(fā)布
git tag -a v1.0 -m 'feature發(fā)布'
git push origin v1.0
之后將release/feature合入develop分支绑嘹，然后刪除
git rebase develop
git checkout develop
git merge release/feature
git push origin :release/feature
7).發(fā)布完成后將release合入master分支，保證master為最新穩(wěn)定版本（實際操作為發(fā)起merge request）
總結(jié)
本篇文章主要針對筆者工作中對于git工作流的一些理解和實踐橘茉，目前我們團隊也是嚴格按照這樣的工作流來完成日常的開發(fā)工作工腋，一個讓團隊成員認可并且有效的工作流才是最適合我們的工作流，任何規(guī)則不是為了限制我們思考畅卓，而是為了讓工作更加高效有序擅腰，盡量減少人為的失誤。git是一個博大精深的東西翁潘，筆者也是不斷在實際應(yīng)用中去理解它趁冈，任何一門技術(shù)的學習也是這樣，就像程序員常用來裝逼的一首詩：
紙上得來終覺淺拜马，絕知此事要躬行渗勘。
