來源：騰訊技術(shù)工程
今天跟大家分享一點(diǎn)鵝廠程序員的 Git 使用經(jīng)驗(yàn)。
介紹四種工作流來更好地理解 Git 的項(xiàng)目使用流程，利用其強(qiáng)大的分支功能為自己的項(xiàng)目構(gòu)筑適配的工作流。
1. 前言
開發(fā)人員在日常開發(fā)過程中，不可避免地會使用到代碼的版本控制工具，如 svn、git 等等，記得在剛剛?cè)肼毜臅r(shí)候，部門使用的主要的 VCS 工具還是 svn，期間有著非常痛苦的 download 經(jīng)歷，下載一份倉庫花了我 2-3 個(gè)小時(shí)，相比于 svn，git 有著非常多的優(yōu)勢，比如倉庫 clone 速度非常快、核心的分支功能等等，后續(xù)公司也在推使用 git 來維護(hù)代碼倉庫，完全摒棄笨重的 svn。
那么，切換到 git 來維護(hù)代碼倉庫，會對我們的日常開發(fā)造成影響嗎？答應(yīng)是顯然的，首先我們需要學(xué)習(xí) git 的基本概念與用法，然后就需要我們在具體的項(xiàng)目實(shí)踐過程中打磨我們的 git 使用技巧，比如靈活的分支、子模塊使用等等，關(guān)于 git 概念或技術(shù)上的介紹，本文不予展開，如果對 git 實(shí)現(xiàn)上的細(xì)節(jié)感興趣的話，可以自行搜索學(xué)習(xí)。
接下來主要跟大家探討的主題是 git 工作流，git 初學(xué)者可能對這個(gè)概念并不是很清晰，腦海中想到的可能是 git 的工作原理之類的，其實(shí)并不是的，git 工作流指的是多人協(xié)作過程中的 git 的使用流程，不涉及技術(shù)細(xì)節(jié)，是一種項(xiàng)目管理、開發(fā)約定的方式。有些同學(xué)可能覺得習(xí)得了 git 三板斧（clone、add commit、push）就算是完成了對 git 的開發(fā)認(rèn)知，其實(shí)咱們可能還停留在最原始的想象之中。
2. 集中式工作流
集中式工作流，這種工作方式對于使用過 svn 的同學(xué)想必會非常的熟悉，讓我們思考下在 svn 下的協(xié)作體驗(yàn)，不同的開發(fā)同學(xué)需要依次將本地的修改提交到服務(wù)器，如果有沖突就先解決本地的沖突再提交，這個(gè)過程中遠(yuǎn)端的服務(wù)器就像是一個(gè)集中管理者，管理著所有人的代碼提交，所以 svn 的開發(fā)協(xié)作流程就是典型的集中式工作流，那切換到 git 場景下，集中式工作流的工作方式又是什么樣的呢？
首先我們看下 git 的基礎(chǔ)操作框架，如圖 2.1 所示：
這里有一份中央倉庫，是存放項(xiàng)目代碼的地方，三個(gè)開發(fā)人員 A、B、C 分別在本地持有一份中央倉庫的拷貝 - 本地倉庫，這里相比于 svn 的框架只是多了一個(gè)本地倉庫；
接下來我們再來看在項(xiàng)目開發(fā)進(jìn)行了一段時(shí)間之后的提交日志是什么樣的，如圖 2.2 所示：
這里是一條最簡單的 master 分支上的提交日志記錄，那相比于 svn 的框架有啥區(qū)別呢，只要把 master 分支字樣改成 trunk 就變成了一條 svn 的提交記錄。
最后，我們考慮以下幾個(gè)條件：
1、有無本地倉庫2、默認(rèn)分支是 master 還是 trunk3、提交操作使用 git command 還是 svn command（細(xì)節(jié)忽略）
我們可以看出 svn 下的集中式工作流同樣適用于 git，只要大家把 svn 相關(guān)的概念全部切換到 git 下即可：1、認(rèn)識本地倉庫2、認(rèn)識默認(rèn)分支 master3、使用 git 的提交命令
以上三點(diǎn)中的前兩點(diǎn)對于集中式工作流下的開發(fā)者其實(shí)是透明的，開發(fā)者只需要將提交命令改成 git 就可以無縫銜接 svn 下的集中式工作流！
所以，svn 切換到 git 的成本其實(shí)還是很低的，只需要你掌握 git 的基礎(chǔ)提交命令！
git 下的集中式工作流，是一種只使用 master 主分支的開發(fā)方式，這種方式簡單明了，但是缺點(diǎn)是不同開發(fā)人員的提交日志混雜在一起，難以定位問題。
3. 功能分支工作流
功能分支工作流，這種工作方式是以集中式工作流為基礎(chǔ)，再為不同功能開發(fā)分配單獨(dú)的功能分支來進(jìn)行的；這種工作流的主干分支仍然是 master 分支，但是開發(fā)者在進(jìn)行日常需求開發(fā)時(shí)不能將代碼直接提交到 master 分支上，一般是為特定的需求新建一個(gè)功能分支，并且取一個(gè)具有描述性的名字，例如：feat-personal-page、issue-#1702，描述性的名稱可以讓其他開發(fā)者快速地明白這個(gè)功能分支的主要作用，提高不同開發(fā)者之間的協(xié)同效率；功能分支功能流的提交日志記錄如圖 3.1 所示：
從圖中可以看出，相比于集中式工作流，分支歷史看起來更加簡潔、合理，讓不同功能的開發(fā)進(jìn)行隔離，避免不同功能代碼之間產(chǎn)生不利的影響。
此外，在功能分支上的需求開發(fā)完成之后，我們需要將分支合并到主干分支 master 上，這時(shí)候需要進(jìn)行的操作是 pull request，為什么要進(jìn)行 PR 操作，而不是直接進(jìn)行代碼的 merge 呢，這里首先需要大家認(rèn)識 PR 是什么操作，其次需要大家了解 PR 操作的意義；
功能需求開發(fā)完成之后，需要將本地功能分支推送到中央倉庫的功能分支上，然后在中央倉庫的功能分支上發(fā)起一個(gè) pull request 請求去將功能分支上的修改合并到 master 分支上，這個(gè)過程一般是在 GIT 的項(xiàng)目主頁上進(jìn)行，公司內(nèi)部就工蜂的項(xiàng)目主頁，如圖 3.2 所示，是 flutter 項(xiàng)目的某一次 PR 詳情：
PR 操作給項(xiàng)目帶來的益處有兩點(diǎn)：1、code review2、討論代碼的公共平臺
前者是每次 PR 操作發(fā)生時(shí)會通知相關(guān)者來檢查待合并的代碼，在檢查過程中即完成了對代碼的檢視，這個(gè)過程保障了 master 分支上的已合并代碼的健壯性；后者則是因?yàn)槊看?PR 都會有一個(gè) PR 詳情主頁，如圖 3.2，每一個(gè)開發(fā)者都可以針對代碼的實(shí)現(xiàn)提出自己的意見，使得討論代碼變成更加便捷高效，且為代碼變更回顧提供了可能。
功能分支工作流是 git 項(xiàng)目開發(fā)非常靈活使用的一種方式，但是對于大型的項(xiàng)目而言，需要為不同的分支分配更加具體的角色。
4.Gitflow 工作流
Gitflow 工作流是目前非常成熟的一個(gè)方案，它定義了一個(gè)圍繞項(xiàng)目發(fā)布的嚴(yán)格分支模型，通過為代碼研發(fā)、項(xiàng)目發(fā)布以及維護(hù)分配獨(dú)立的分支來讓項(xiàng)目的迭代過程更加地順暢，不同于之前的集中式工作流以及功能分支工作流，gitflow 工作流常駐的分支有兩個(gè)：主干分支 master、開發(fā)分支 dev，此外針對項(xiàng)目研發(fā)的各個(gè)階段，設(shè)定了特定的分支。
階段分支常駐 master、dev 研發(fā) feature 熱修復(fù) hotfix 發(fā)布 release
首先針對常駐分支，如圖 4.1
常駐分支表示在項(xiàng)目提交歷史中一直存在的分支，這里 master 分支主要跟蹤項(xiàng)目正式發(fā)布的代碼歷史，dev 分支主要跟蹤項(xiàng)目代碼研發(fā)的提交歷史；此外在 master 分支上通常會為某次版本發(fā)布分配一個(gè)標(biāo)簽來記錄版本號，這為以后項(xiàng)目排查定位提供便利。
接下來，我們來看 gitflow 工作流中，代碼研發(fā)階段的工作流程。
如圖 4.2 所示，開發(fā)階段開啟某一個(gè)需求時(shí)需要從 dev 分支上新建功能分支 feature，圖中所示為兩個(gè) feature 分支，代表同時(shí)有兩個(gè)功能在開發(fā)中，這里的 feature 分支使用跟功能分支工作流中的使用方式是一樣的，在需求開發(fā)完成之后需要提交 PR 請求合并進(jìn) dev 分支，完成之后即可刪除對應(yīng)的功能分支。
搜索公眾號互聯(lián)網(wǎng)架構(gòu)師后臺回復(fù)“2T”，獲取一份驚喜禮包。
很多時(shí)候，在需求研發(fā)過程中，線上的代碼可能會出現(xiàn)問題，這時(shí)候需要我們進(jìn)行及時(shí)的修復(fù)，這就是項(xiàng)目迭代過程中的熱修復(fù)階段。
如圖 4.3 所示，假設(shè)我們在開發(fā)的過程中線上出現(xiàn)了一個(gè) bug，這時(shí)候我們需要從 master 的標(biāo)簽 v0.1 上檢出一份分支代碼 hotfix，修復(fù)并驗(yàn)證好了之后，需要將 hotfix 代碼分別合并到 master /dev 分支上，并在 master 的提交上打上一個(gè)標(biāo)簽 v0.2，這里需要將熱修復(fù)的代碼分別合并進(jìn)兩個(gè)常駐分支是因?yàn)樾枰Ｕ蟽蛇叴a的一致性。
最后，我們來看下項(xiàng)目迭代的發(fā)布階段，我們需要將之前功能開發(fā)完成的特性發(fā)布到線上去，如圖 4.4 所示
首先在 dev 分支的提交處新建 release 分支，在這個(gè)分支上進(jìn)行 bug 修復(fù)、面向發(fā)布的一些任務(wù)，這個(gè)分支不做任何功能上的任務(wù)，完成之后將 release 分支再分別合并進(jìn) master/dev 分支，并在 master 提交上打上標(biāo)簽 v1.0，這樣一個(gè)發(fā)布階段的代碼操作就完成了
最后我們來看發(fā)布之后的目前的日志記錄情況，如圖 4.5 所示，這里可以將沒有用的分支 hotfix、release、feature 均刪除了，可以看出我們的常駐分支就 master/dev，最下面的 feature 表示仍在開發(fā)中。
gitflow 工作流是目前比較很成熟的方案，它的優(yōu)點(diǎn)有：
1、發(fā)布迭代流程更順暢2、使得代碼有了更加嚴(yán)謹(jǐn)?shù)捻?xiàng)目結(jié)構(gòu)，方便定位排查問題
大型的項(xiàng)目 / 迭代速度快的推薦使用這種工作流程！
5.Forking 工作流
最后介紹一種開源項(xiàng)目常用的工作流 ——Forking 工作流，介紹之前首先需要了解什么是 fork 操作，如圖 5.1 所示
fork 操作是在個(gè)人遠(yuǎn)程倉庫新建一份目標(biāo)遠(yuǎn)程倉庫的拷貝，操作很簡單，比如 github 上在項(xiàng)目的主頁點(diǎn)擊 fork 按鈕即可。
明白了 fork 操作之后，我們來看下 forking 工作流的流程，如圖 5.2 所示：
首先開發(fā)者 A 擁有一個(gè)遠(yuǎn)端倉庫，這時(shí)候有一個(gè)開發(fā)者 C 也想?yún)⑴c A 的這個(gè)項(xiàng)目的開發(fā)工作，那他就可以 fork 一份 A 的這個(gè)倉庫，之后在 c 的個(gè)人倉庫里就有了這份代碼庫，后續(xù)開發(fā)者 C 就可以在自己的這個(gè)項(xiàng)目里進(jìn)行開發(fā)工作，c 在完成了某個(gè)功能的實(shí)現(xiàn)之后，可以給 A 的倉庫發(fā)一個(gè) PR 請求，這時(shí)候會通知到開發(fā)者 A 有新的 PR，A 如果有問題可以直接在這個(gè) PR 里提，開發(fā)者 C 可以進(jìn)行進(jìn)一步的修改，最后 A 通過了 C 的這份 PR 請求，就會將 C 的代碼合并進(jìn) A 的倉庫，這樣就完成了 A / 代碼庫新特性的開發(fā)。同時(shí)如果有其他開發(fā)者對 A 的項(xiàng)目有興趣也會進(jìn)行相同的操作。
這里注意到 開發(fā)者 B/C 并不是 A 代碼庫的開發(fā)人員，而是第三方開發(fā)者，所以這種工作流主要用于開源項(xiàng)目！
6. 總結(jié)
最后回顧下這幾種 git 工作流，集中式工作流可以說是 git 工作流的基礎(chǔ)，初學(xué)者可以無縫地從 svn 的模式切換到 git 的模式；功能分支工作流在集中式的基礎(chǔ)上又引入了功能分支，靈活地利用了 git 的分支特性，功能分離 / PR 優(yōu)化了日常工作的效率；gitflow 工作流則是為大型項(xiàng)目的迭代過程服務(wù)的，指定了一個(gè)嚴(yán)格的分支模型，使得迭代流程更加順暢；forking 工作流則是開源項(xiàng)目的首選，想要為開源項(xiàng)目做貢獻(xiàn)就必須要懂得這種工作流！
當(dāng)然，以上描述的這些工作流并不是實(shí)際工作中 git 使用的準(zhǔn)則，這只是一些推薦的使用方式，在具體的項(xiàng)目研發(fā)過程中，我們需要結(jié)合項(xiàng)目以及團(tuán)隊(duì)現(xiàn)狀作出取舍，總結(jié)出適合自己團(tuán)隊(duì)的工作流，才能讓 git 更好地為我們服務(wù)！