開(kāi)發(fā)人員在日常開(kāi)發(fā)過(guò)程中，不可避免地會(huì)使用到代碼的版本控制工具，如 svn、git 等等，記得在剛剛?cè)肼毜臅r(shí)候，部門(mén)使用的主要的 VCS 工具還是 svn，期間有著非常痛苦的 download 經(jīng)歷，下載一份倉(cāng)庫(kù)花了我 2-3 個(gè)小時(shí)，相比于 svn，git 有著非常多的優(yōu)勢(shì)，比如倉(cāng)庫(kù) clone 速度非?？?、核心的分支功能等等，后續(xù)公司也在推使用 git 來(lái)維護(hù)代碼倉(cāng)庫(kù)，完全摒棄笨重的 svn。

那么，切換到 git 來(lái)維護(hù)代碼倉(cāng)庫(kù)，會(huì)對(duì)我們的日常開(kāi)發(fā)造成影響嗎？答應(yīng)是顯然的，首先我們需要學(xué)習(xí) git 的基本概念與用法，然后就需要我們?cè)诰唧w的項(xiàng)目實(shí)踐過(guò)程中打磨我們的 git 使用技巧，比如靈活的分支、子模塊使用等等，關(guān)于 git 概念或技術(shù)上的介紹，本文不予展開(kāi)，如果對(duì) git 實(shí)現(xiàn)上的細(xì)節(jié)感興趣的話，可以自行搜索學(xué)習(xí)。

接下來(lái)主要跟大家探討的主題是 git 工作流，git 初學(xué)者可能對(duì)這個(gè)概念并不是很清晰，腦海中想到的可能是 git 的工作原理之類(lèi)的，其實(shí)并不是的，git 工作流指的是多人協(xié)作過(guò)程中的 git 的使用流程，不涉及技術(shù)細(xì)節(jié)，是一種項(xiàng)目管理、開(kāi)發(fā)約定的方式。有些同學(xué)可能覺(jué)得習(xí)得了 git 三板斧（clone、add commit、push）就算是完成了對(duì) git 的開(kāi)發(fā)認(rèn)知，其實(shí)咱們可能還停留在最原始的想象之中。

2. 集中式工作流

集中式工作流，這種工作方式對(duì)于使用過(guò) svn 的同學(xué)想必會(huì)非常的熟悉，讓我們思考下在 svn 下的協(xié)作體驗(yàn)，不同的開(kāi)發(fā)同學(xué)需要依次將本地的修改提交到服務(wù)器，如果有沖突就先解決本地的沖突再提交，這個(gè)過(guò)程中遠(yuǎn)端的服務(wù)器就像是一個(gè)集中管理者，管理著所有人的代碼提交，所以 svn 的開(kāi)發(fā)協(xié)作流程就是典型的集中式工作流，那切換到 git 場(chǎng)景下，集中式工作流的工作方式又是什么樣的呢？

首先我們看下 git 的基礎(chǔ)操作框架，如圖 2.1 所示：

這里有一份中央倉(cāng)庫(kù)，是存放項(xiàng)目代碼的地方，三個(gè)開(kāi)發(fā)人員 A、B、C 分別在本地持有一份中央倉(cāng)庫(kù)的拷貝 - 本地倉(cāng)庫(kù)，這里相比于 svn 的框架只是多了一個(gè)本地倉(cāng)庫(kù)；

接下來(lái)我們?cè)賮?lái)看在項(xiàng)目開(kāi)發(fā)進(jìn)行了一段時(shí)間之后的提交日志是什么樣的，如圖 2.2 所示：

這里是一條最簡(jiǎn)單的 master 分支上的提交日志記錄，那相比于 svn 的框架有啥區(qū)別呢，只要把 master 分支字樣改成 trunk 就變成了一條 svn 的提交記錄。

最后，我們考慮以下幾個(gè)條件：

1、有無(wú)本地倉(cāng)庫(kù)2、默認(rèn)分支是 master 還是 trunk3、提交操作使用 git command 還是 svn command（細(xì)節(jié)忽略）

我們可以看出 svn 下的集中式工作流同樣適用于 git，只要大家把 svn 相關(guān)的概念全部切換到 git 下即可：1、認(rèn)識(shí)本地倉(cāng)庫(kù)2、認(rèn)識(shí)默認(rèn)分支 master3、使用 git 的提交命令

以上三點(diǎn)中的前兩點(diǎn)對(duì)于集中式工作流下的開(kāi)發(fā)者其實(shí)是透明的，開(kāi)發(fā)者只需要將提交命令改成 git 就可以無(wú)縫銜接 svn 下的集中式工作流！

所以，svn 切換到 git 的成本其實(shí)還是很低的，只需要你掌握 git 的基礎(chǔ)提交命令！

git 下的集中式工作流，是一種只使用 master 主分支的開(kāi)發(fā)方式，這種方式簡(jiǎn)單明了，但是缺點(diǎn)是不同開(kāi)發(fā)人員的提交日志混雜在一起，難以定位問(wèn)題。

3. 功能分支工作流

功能分支工作流，這種工作方式是以集中式工作流為基礎(chǔ)，再為不同功能開(kāi)發(fā)分配單獨(dú)的功能分支來(lái)進(jìn)行的；這種工作流的主干分支仍然是 master 分支，但是開(kāi)發(fā)者在進(jìn)行日常需求開(kāi)發(fā)時(shí)不能將代碼直接提交到 master 分支上，一般是為特定的需求新建一個(gè)功能分支，并且取一個(gè)具有描述性的名字，例如：feat-personal-page、issue-#1702，描述性的名稱(chēng)可以讓其他開(kāi)發(fā)者快速地明白這個(gè)功能分支的主要作用，提高不同開(kāi)發(fā)者之間的協(xié)同效率；功能分支功能流的提交日志記錄如圖 3.1 所示：

從圖中可以看出，相比于集中式工作流，分支歷史看起來(lái)更加簡(jiǎn)潔、合理，讓不同功能的開(kāi)發(fā)進(jìn)行隔離，避免不同功能代碼之間產(chǎn)生不利的影響。

此外，在功能分支上的需求開(kāi)發(fā)完成之后，我們需要將分支合并到主干分支 master 上，這時(shí)候需要進(jìn)行的操作是 pull request，為什么要進(jìn)行 PR 操作，而不是直接進(jìn)行代碼的 merge 呢，這里首先需要大家認(rèn)識(shí) PR 是什么操作，其次需要大家了解 PR 操作的意義；

功能需求開(kāi)發(fā)完成之后，需要將本地功能分支推送到中央倉(cāng)庫(kù)的功能分支上，然后在中央倉(cāng)庫(kù)的功能分支上發(fā)起一個(gè) pull request 請(qǐng)求去將功能分支上的修改合并到 master 分支上，這個(gè)過(guò)程一般是在 GIT 的項(xiàng)目主頁(yè)上進(jìn)行，公司內(nèi)部就工蜂的項(xiàng)目主頁(yè)，如圖 3.2 所示，是 flutter 項(xiàng)目的某一次 PR 詳情：

PR 操作給項(xiàng)目帶來(lái)的益處有兩點(diǎn)：1、code review2、討論代碼的公共平臺(tái)

前者是每次 PR 操作發(fā)生時(shí)會(huì)通知相關(guān)者來(lái)檢查待合并的代碼，在檢查過(guò)程中即完成了對(duì)代碼的檢視，這個(gè)過(guò)程保障了 master 分支上的已合并代碼的健壯性；后者則是因?yàn)槊看?PR 都會(huì)有一個(gè) PR 詳情主頁(yè)，如圖 3.2，每一個(gè)開(kāi)發(fā)者都可以針對(duì)代碼的實(shí)現(xiàn)提出自己的意見(jiàn)，使得討論代碼變成更加便捷高效，且為代碼變更回顧提供了可能。

功能分支工作流是 git 項(xiàng)目開(kāi)發(fā)非常靈活使用的一種方式，但是對(duì)于大型的項(xiàng)目而言，需要為不同的分支分配更加具體的角色。

4.Gitflow 工作流

Gitflow 工作流是目前非常成熟的一個(gè)方案，它定義了一個(gè)圍繞項(xiàng)目發(fā)布的嚴(yán)格分支模型，通過(guò)為代碼研發(fā)、項(xiàng)目發(fā)布以及維護(hù)分配獨(dú)立的分支來(lái)讓項(xiàng)目的迭代過(guò)程更加地順暢，不同于之前的集中式工作流以及功能分支工作流，gitflow 工作流常駐的分支有兩個(gè)：主干分支 master、開(kāi)發(fā)分支 dev，此外針對(duì)項(xiàng)目研發(fā)的各個(gè)階段，設(shè)定了特定的分支。

階段分支常駐 master、dev 研發(fā) feature 熱修復(fù) hotfix 發(fā)布 release

首先針對(duì)常駐分支，如圖 4.1

常駐分支表示在項(xiàng)目提交歷史中一直存在的分支，這里 master 分支主要跟蹤項(xiàng)目正式發(fā)布的代碼歷史，dev 分支主要跟蹤項(xiàng)目代碼研發(fā)的提交歷史；此外在 master 分支上通常會(huì)為某次版本發(fā)布分配一個(gè)標(biāo)簽來(lái)記錄版本號(hào)，這為以后項(xiàng)目排查定位提供便利。

接下來(lái)，我們來(lái)看 gitflow 工作流中，代碼研發(fā)階段的工作流程。

如圖 4.2 所示，開(kāi)發(fā)階段開(kāi)啟某一個(gè)需求時(shí)需要從 dev 分支上新建功能分支 feature，圖中所示為兩個(gè) feature 分支，代表同時(shí)有兩個(gè)功能在開(kāi)發(fā)中，這里的 feature 分支使用跟功能分支工作流中的使用方式是一樣的，在需求開(kāi)發(fā)完成之后需要提交 PR 請(qǐng)求合并進(jìn) dev 分支，完成之后即可刪除對(duì)應(yīng)的功能分支。

很多時(shí)候，在需求研發(fā)過(guò)程中，線上的代碼可能會(huì)出現(xiàn)問(wèn)題，這時(shí)候需要我們進(jìn)行及時(shí)的修復(fù)，這就是項(xiàng)目迭代過(guò)程中的熱修復(fù)階段。

如圖 4.3 所示，假設(shè)我們?cè)陂_(kāi)發(fā)的過(guò)程中線上出現(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的一致性。

最后，我們來(lái)看下項(xiàng)目迭代的發(fā)布階段，我們需要將之前功能開(kāi)發(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ā)布階段的代碼操作就完成了

最后我們來(lái)看發(fā)布之后的目前的日志記錄情況，如圖 4.5 所示，這里可以將沒(méi)有用的分支 hotfix、release、feature 均刪除了，可以看出我們的常駐分支就 master/dev，最下面的 feature 表示仍在開(kāi)發(fā)中。

gitflow 工作流是目前比較很成熟的方案，它的優(yōu)點(diǎn)有：

1、發(fā)布迭代流程更順暢2、使得代碼有了更加嚴(yán)謹(jǐn)?shù)捻?xiàng)目結(jié)構(gòu)，方便定位排查問(wèn)題

大型的項(xiàng)目 / 迭代速度快的推薦使用這種工作流程！

5.Forking 工作流

最后介紹一種開(kāi)源項(xiàng)目常用的工作流 ——Forking 工作流，介紹之前首先需要了解什么是 fork 操作，如圖 5.1 所示

fork 操作是在個(gè)人遠(yuǎn)程倉(cāng)庫(kù)新建一份目標(biāo)遠(yuǎn)程倉(cāng)庫(kù)的拷貝，操作很簡(jiǎn)單，比如 github 上在項(xiàng)目的主頁(yè)點(diǎn)擊 fork 按鈕即可。

明白了 fork 操作之后，我們來(lái)看下 forking 工作流的流程，如圖 5.2 所示：

首先開(kāi)發(fā)者 A 擁有一個(gè)遠(yuǎn)端倉(cāng)庫(kù)，這時(shí)候有一個(gè)開(kāi)發(fā)者 C 也想?yún)⑴c A 的這個(gè)項(xiàng)目的開(kāi)發(fā)工作，那他就可以 fork 一份 A 的這個(gè)倉(cāng)庫(kù)，之后在 c 的個(gè)人倉(cāng)庫(kù)里就有了這份代碼庫(kù)，后續(xù)開(kāi)發(fā)者 C 就可以在自己的這個(gè)項(xiàng)目里進(jìn)行開(kāi)發(fā)工作，c 在完成了某個(gè)功能的實(shí)現(xiàn)之后，可以給 A 的倉(cāng)庫(kù)發(fā)一個(gè) PR 請(qǐng)求，這時(shí)候會(huì)通知到開(kāi)發(fā)者 A 有新的 PR，A 如果有問(wèn)題可以直接在這個(gè) PR 里提，開(kāi)發(fā)者 C 可以進(jìn)行進(jìn)一步的修改，最后 A 通過(guò)了 C 的這份 PR 請(qǐng)求，就會(huì)將 C 的代碼合并進(jìn) A 的倉(cāng)庫(kù)，這樣就完成了 A / 代碼庫(kù)新特性的開(kāi)發(fā)。同時(shí)如果有其他開(kāi)發(fā)者對(duì) A 的項(xiàng)目有興趣也會(huì)進(jìn)行相同的操作。

這里注意到 開(kāi)發(fā)者 B/C 并不是 A 代碼庫(kù)的開(kāi)發(fā)人員，而是第三方開(kāi)發(fā)者，所以這種工作流主要用于開(kāi)源項(xiàng)目！

6. 總結(jié)

最后回顧下這幾種 git 工作流，集中式工作流可以說(shuō)是 git 工作流的基礎(chǔ)，初學(xué)者可以無(wú)縫地從 svn 的模式切換到 git 的模式；功能分支工作流在集中式的基礎(chǔ)上又引入了功能分支，靈活地利用了 git 的分支特性，功能分離 / PR 優(yōu)化了日常工作的效率；gitflow 工作流則是為大型項(xiàng)目的迭代過(guò)程服務(wù)的，指定了一個(gè)嚴(yán)格的分支模型，使得迭代流程更加順暢；forking 工作流則是開(kāi)源項(xiàng)目的首選，想要為開(kāi)源項(xiàng)目做貢獻(xiàn)就必須要懂得這種工作流！

當(dāng)然，以上描述的這些工作流并不是實(shí)際工作中 git 使用的準(zhǔn)則，這只是一些推薦的使用方式，在具體的項(xiàng)目研發(fā)過(guò)程中，我們需要結(jié)合項(xiàng)目以及團(tuán)隊(duì)現(xiàn)狀作出取舍，總結(jié)出適合自己團(tuán)隊(duì)的工作流，才能讓 git 更好地為我們服務(wù)！