Git 工作流的一些經(jīng)驗(yàn)分享
原創(chuàng) 2017-02-16 巫山老妖小巫技術(shù)博客
筆者使用git有一段時間了速那，踩過不少坑标沪，這里分享下我在git工作流方面的一些經(jīng)驗(yàn)贮配。
什么是Git工作流囊卜？
Git工作流你可以理解為工作中團(tuán)隊(duì)成員遵守的一種代碼管理方案半火，在Git中有以下幾種工作流方案作為方案指導(dǎo)：
- 集中式工作流
- 功能開發(fā)工作流
- Gitflow工作流
- Forking工作流
下面針對性說下每個工作流可能使用到的場景和適用性：
集中式工作流
這種工作方式跟svn類似越妈，它只有一個master分支，開發(fā)者會先把遠(yuǎn)程的倉庫克隆到本地钮糖，之后的修改和提交都在本地操作梅掠，直到在某個合適的時間點(diǎn)將本地的代碼合入到遠(yuǎn)程master酌住。這種工作流比較適合小團(tuán)隊(duì)，因?yàn)樾F(tuán)隊(duì)可能不會太多的協(xié)作和合流的動作阎抒。
功能開發(fā)工作流
這種工作流關(guān)注功能開發(fā)酪我，不直接往master提交代碼保證它是穩(wěn)定并且干凈的，而是從master拉取feature分支進(jìn)行功能開發(fā)且叁，團(tuán)隊(duì)成員根據(jù)分工拉取不同的功能分支來進(jìn)行不同的功能開發(fā)都哭，這樣就可以完全隔離開每個人的工作。當(dāng)功能開發(fā)完成后逞带，會向master分支發(fā)起Pull Request欺矫，只有審核通過的代碼才真正允許合入master，這樣就加強(qiáng)了團(tuán)隊(duì)成員之間的代碼交流展氓，也就是我們常說的Code Review穆趴。
Gitflow工作流
這個工作流其實(shí)也是我們團(tuán)隊(duì)采用的工作流，這也是很多團(tuán)隊(duì)會采用的工作流遇汞，它會相對復(fù)雜一點(diǎn)未妹，但它非常適合用來管理大型項(xiàng)目的發(fā)布和維護(hù)，后面筆者也會詳細(xì)講下這一塊空入。貫穿整個開發(fā)周期络它，master和develop分支是一直存在的，master分支可以被視為穩(wěn)定的分支执庐，而develop分支是相對穩(wěn)定的分支酪耕，特性開發(fā)會在feature分支上進(jìn)行，發(fā)布會在release分支上進(jìn)行轨淌，而bug修復(fù)則會在hotfix分支上進(jìn)行迂烁。筆者也是花了不少時間才熟練掌握整個工作流，期間遇到不少坑递鹉，后面會跟大家分享下盟步。
Forking工作流
Forking工作流對于開源項(xiàng)目貢獻(xiàn)者一定不陌生了，它有一個公開的中央倉庫躏结，其他貢獻(xiàn)者可以Fork（克氯磁獭）這個倉庫作為你自己的私有倉庫，開源項(xiàng)目維護(hù)者可以直接往中央倉庫push代碼媳拴，而代碼貢獻(xiàn)者只能將代碼push到自己的私有倉庫黄橘，只有項(xiàng)目維護(hù)者接受代碼貢獻(xiàn)者往中央倉庫發(fā)起的pull request才會真正合入。
小結(jié)一下
上面已經(jīng)大致講了在git當(dāng)中的四種比較常見的工作流屈溉，都是需要開發(fā)者去實(shí)踐理解的塞关。
關(guān)于git工作流，只有選用最合適自己團(tuán)隊(duì)的工作流才能有效的提高開發(fā)效率子巾，上面提到的一些工作流模式都有各自的適用場景帆赢，如何選用適合自己團(tuán)隊(duì)的工作流得結(jié)合團(tuán)隊(duì)成員的實(shí)際情況小压，看團(tuán)隊(duì)成員對于工作流的理解程度，還有對于工作流的執(zhí)行程度椰于。
我們團(tuán)隊(duì)的一些實(shí)踐
現(xiàn)在講下我們團(tuán)隊(duì)針對Gitflow的一些實(shí)踐：
master分支
- 主分支
- 保持穩(wěn)定
- 不允許直接往這個分支提交代碼怠益，只允許往這個分支發(fā)起merge request
- 只允許release分支和hotfix分支進(jìn)行合流
develop分支
- 開發(fā)分支
- 相對穩(wěn)定的分支
- 用于日常開發(fā)，包括代碼優(yōu)化瘾婿、功能性開發(fā)
feature分支
- 特性分支
- 從develop分支拉取蜻牢，用于下個迭代版本的功能特性開發(fā)
- 功能開發(fā)完畢合并到develop分支
release分支
- 發(fā)布分支
- 從develop分支拉取
- 用于回歸測試，bug修復(fù)
- 發(fā)布完成后打tag并合入master和develop
hotfix分支
- 熱更新分支
- 從develop分支拉取
- 用于緊急修復(fù)上線版本的問題
- 修復(fù)后打tag并合入master和develop
大家可能會發(fā)現(xiàn)我們這個跟標(biāo)準(zhǔn)的Gitflow工作流有些差別偏陪，其實(shí)也沒有什么標(biāo)準(zhǔn)不標(biāo)準(zhǔn)的孩饼，前面說到要結(jié)合團(tuán)隊(duì)的實(shí)際情況，我們團(tuán)隊(duì)對于目前所采用的工作方式都是達(dá)成共識的竹挡，所以有一些差異并沒有關(guān)系。
說了這么久立膛，還沒有一句git命令揪罕，那就讓大家感受一下吧（感謝Bugly小色熊整理）：
1). 首先將遠(yuǎn)程代碼拉取到本地
git clone xxx
git checkout -b develop origin/develop
2).新建feature分支
git checkout -b feature
3).多人在feature上開發(fā)，如果中途需要將develop的變更合入feature宝泵，所有人需要將本地的代碼變更提交到遠(yuǎn)程
git fetch origin
git rebase origin/feature
git push origin feature
然后由feature負(fù)責(zé)人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ā)完成后，所有人需要將本地的代碼變更提交到遠(yuǎn)程
git fetch origin
git rebase origin/feature
git push origin feature
然后由feature負(fù)責(zé)人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修復(fù)在release/feature上
git checkout develop
git checkout -b release/feature
release/feature分支的同步合并與feature分支相同
6).release/feature分支bug修復(fù)完成后茬祷，拉取對應(yīng)的tag推送遠(yuǎn)程進(jìn)行發(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)定版本（實(shí)際操作為發(fā)起merge request）
總結(jié)
本篇文章主要針對筆者工作中對于git工作流的一些理解和實(shí)踐祭犯，目前我們團(tuán)隊(duì)也是嚴(yán)格按照這樣的工作流來完成日常的開發(fā)工作秸妥，一個讓團(tuán)隊(duì)成員認(rèn)可并且有效的工作流才是最適合我們的工作流，任何規(guī)則不是為了限制我們思考沃粗，而是為了讓工作更加高效有序粥惧，盡量減少人為的失誤尝胆。git是一個博大精深的東西几于，筆者也是不斷在實(shí)際應(yīng)用中去理解它，任何一門技術(shù)的學(xué)習(xí)也是這樣，就像程序員常用來裝逼的一首詩：
紙上得來終覺淺挺尿，絕知此事要躬行。
