鵝廠究竟是如何使用 Git 的?

來源：騰訊技術工程

今天跟大家分享一點鵝廠程序員的 Git 使用經驗。

介紹四種工作流來更好地理解 Git 的項目使用流程，利用其強大的分支功能為自己的項目構筑適配的工作流。

1. 前言

開發(fā)人員在日常開發(fā)過程中，不可避免地會使用到代碼的版本控制工具，如 svn、git 等等，記得在剛剛入職的時候，部門使用的主要的 VCS 工具還是 svn，期間有著非常痛苦的 download 經歷，下載一份倉庫花了我 2-3 個小時，相比于 svn，git 有著非常多的優(yōu)勢，比如倉庫 clone 速度非常快、核心的分支功能等等，后續(xù)公司也在推使用 git 來維護代碼倉庫，完全摒棄笨重的 svn。

那么，切換到 git 來維護代碼倉庫，會對我們的日常開發(fā)造成影響嗎？答應是顯然的，首先我們需要學習 git 的基本概念與用法，然后就需要我們在具體的項目實踐過程中打磨我們的 git 使用技巧，比如靈活的分支、子模塊使用等等，關于 git 概念或技術上的介紹，本文不予展開，如果對 git 實現(xiàn)上的細節(jié)感興趣的話，可以自行搜索學習。

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

2. 集中式工作流

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

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

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

接下來我們再來看在項目開發(fā)進行了一段時間之后的提交日志是什么樣的，如圖 2.2 所示：

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

最后，我們考慮以下幾個條件：

1、有無本地倉庫2、默認分支是 master 還是 trunk3、提交操作使用 git command 還是 svn command（細節(jié)忽略）

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

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

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

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

3. 功能分支工作流

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

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

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

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

PR 操作給項目帶來的益處有兩點：1、code review2、討論代碼的公共平臺

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

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

4.Gitflow 工作流

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

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

首先針對常駐分支，如圖 4.1

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

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

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

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

如圖 4.3 所示，假設我們在開發(fā)的過程中線上出現(xiàn)了一個 bug，這時候我們需要從 master 的標簽 v0.1 上檢出一份分支代碼 hotfix，修復并驗證好了之后，需要將 hotfix 代碼分別合并到 master /dev 分支上，并在 master 的提交上打上一個標簽 v0.2，這里需要將熱修復的代碼分別合并進兩個常駐分支是因為需要保障兩邊代碼的一致性。

最后，我們來看下項目迭代的發(fā)布階段，我們需要將之前功能開發(fā)完成的特性發(fā)布到線上去，如圖 4.4 所示

首先在 dev 分支的提交處新建 release 分支，在這個分支上進行 bug 修復、面向發(fā)布的一些任務，這個分支不做任何功能上的任務，完成之后將 release 分支再分別合并進 master/dev 分支，并在 master 提交上打上標簽 v1.0，這樣一個發(fā)布階段的代碼操作就完成了

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

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

1、發(fā)布迭代流程更順暢2、使得代碼有了更加嚴謹?shù)捻椖拷Y構，方便定位排查問題

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

5.Forking 工作流

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

fork 操作是在個人遠程倉庫新建一份目標遠程倉庫的拷貝，操作很簡單，比如 github 上在項目的主頁點擊 fork 按鈕即可。

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

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

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

6. 總結

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

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

視頻號開通啦，

是關于國外程序員題材的視頻號

長按二維碼關注