鵝廠是如何使用 Git 的？
轉自：騰訊技術工程
今天跟大家分享一點鵝廠程序員的 Git 使用經驗。
介紹四種工作流來更好地理解 Git 的項目使用流程，利用其強大的分支功能爲自己的項目構築適配的工作流。
1. 前言
開發人員在日常開發過程中，不可避免地會使用到代碼的版本控制工具，如 svn、git 等等，記得在剛剛入職的時候，部門使用的主要的 VCS 工具還是 svn，期間有着非常痛苦的 download 經歷，下載一份倉庫花了我 2-3 個小時，相比於 svn，git 有着非常多的優勢，比如倉庫 clone 速度非常快、核心的分支功能等等，後續公司也在推使用 git 來維護代碼倉庫，完全摒棄笨重的 svn。
那麼，切換到 git 來維護代碼倉庫，會對我們的日常開發造成影響嗎？答應是顯然的，首先我們需要學習 git 的基本概念與用法，然後就需要我們在具體的項目實踐過程中打磨我們的 git 使用技巧，比如靈活的分支、子模塊使用等等，關於 git 概念或技術上的介紹，本文不予展開，如果對 git 實現上的細節感興趣的話，可以自行搜索學習。
接下來主要跟大家探討的主題是 git 工作流，git 初學者可能對這個概念並不是很清晰，腦海中想到的可能是 git 的工作原理之類的，其實並不是的，git 工作流指的是多人協作過程中的 git 的使用流程，不涉及技術細節，是一種項目管理、開發約定的方式。有些同學可能覺得習得了 git 三板斧（clone、add commit、push）就算是完成了對 git 的開發認知，其實咱們可能還停留在最原始的想象之中。
2. 集中式工作流
集中式工作流，這種工作方式對於使用過 svn 的同學想必會非常的熟悉，讓我們思考下在 svn 下的協作體驗，不同的開發同學需要依次將本地的修改提交到服務器，如果有衝突就先解決本地的衝突再提交，這個過程中遠端的服務器就像是一個集中管理者，管理着所有人的代碼提交，所以 svn 的開發協作流程就是典型的集中式工作流，那切換到 git 場景下，集中式工作流的工作方式又是什麼樣的呢？
首先我們看下 git 的基礎操作框架，如圖 2.1 所示：
這裏有一份中央倉庫，是存放項目代碼的地方，三個開發人員 A、B、C 分別在本地持有一份中央倉庫的拷貝 - 本地倉庫，這裏相比於 svn 的框架只是多了一個本地倉庫；
接下來我們再來看在項目開發進行了一段時間之後的提交日誌是什麼樣的，如圖 2.2 所示：
這裏是一條最簡單的 master 分支上的提交日誌記錄，那相比於 svn 的框架有啥區別呢，只要把 master 分支字樣改成 trunk 就變成了一條 svn 的提交記錄。
最後，我們考慮以下幾個條件：
1、有無本地倉庫 2、默認分支是 master 還是 trunk3、提交操作使用 git command 還是 svn command（細節忽略）
我們可以看出 svn 下的集中式工作流同樣適用於 git，只要大家把 svn 相關的概念全部切換到 git 下即可：1、認識本地倉庫 2、認識默認分支 master3、使用 git 的提交命令
以上三點中的前兩點對於集中式工作流下的開發者其實是透明的，開發者只需要將提交命令改成 git 就可以無縫銜接 svn 下的集中式工作流！
所以，svn 切換到 git 的成本其實還是很低的，只需要你掌握 git 的基礎提交命令！
3. 功能分支工作流
此外，在功能分支上的需求開發完成之後，我們需要將分支合併到主幹分支 master 上，這時候需要進行的操作是 pull request，爲什麼要進行 PR 操作，而不是直接進行代碼的 merge 呢，這裏首先需要大家認識 PR 是什麼操作，其次需要大家瞭解 PR 操作的意義；
PR 操作給項目帶來的益處有兩點：1、code review2、討論代碼的公共平臺
前者是每次 PR 操作發生時會通知相關者來檢查待合併的代碼，在檢查過程中即完成了對代碼的檢視，這個過程保障了 master 分支上的已合併代碼的健壯性；後者則是因爲每次 PR 都會有一個 PR 詳情主頁，如圖 3.2，每一個開發者都可以針對代碼的實現提出自己的意見，使得討論代碼變成更加便捷高效，且爲代碼變更回顧提供了可能。
功能分支工作流是 git 項目開發非常靈活使用的一種方式，但是對於大型的項目而言，需要爲不同的分支分配更加具體的角色。
4.Gitflow 工作流
Gitflow 工作流是目前非常成熟的一個方案，它定義了一個圍繞項目發佈的嚴格分支模型，通過爲代碼研發、項目發佈以及維護分配獨立的分支來讓項目的迭代過程更加地順暢，不同於之前的集中式工作流以及功能分支工作流，gitflow 工作流常駐的分支有兩個：主幹分支 master、開發分支 dev，此外針對項目研發的各個階段，設定了特定的分支。
階段分支常駐 master、dev 研發 feature 熱修復 hotfix 發佈 release
首先針對常駐分支，如圖 4.1
常駐分支表示在項目提交歷史中一直存在的分支，這裏 master 分支主要跟蹤項目正式發佈的代碼歷史，dev 分支主要跟蹤項目代碼研發的提交歷史；此外在 master 分支上通常會爲某次版本發佈分配一個標籤來記錄版本號，這爲以後項目排查定位提供便利。
接下來，我們來看 gitflow 工作流中，代碼研發階段的工作流程。
如圖 4.2 所示，開發階段開啓某一個需求時需要從 dev 分支上新建功能分支 feature，圖中所示爲兩個 feature 分支，代表同時有兩個功能在開發中，這裏的 feature 分支使用跟功能分支工作流中的使用方式是一樣的，在需求開發完成之後需要提交 PR 請求合併進 dev 分支，完成之後即可刪除對應的功能分支。
很多時候，在需求研發過程中，線上的代碼可能會出現問題，這時候需要我們進行及時的修復，這就是項目迭代過程中的熱修復階段。
如圖 4.3 所示，假設我們在開發的過程中線上出現了一個 bug，這時候我們需要從 master 的標籤 v0.1 上檢出一份分支代碼 hotfix，修復並驗證好了之後，需要將 hotfix 代碼分別合併到 master /dev 分支上，並在 master 的提交上打上一個標籤 v0.2，這裏需要將熱修復的代碼分別合併進兩個常駐分支是因爲需要保障兩邊代碼的一致性。
最後，我們來看下項目迭代的發佈階段，我們需要將之前功能開發完成的特性發布到線上去，如圖 4.4 所示
首先在 dev 分支的提交處新建 release 分支，在這個分支上進行 bug 修復、面向發佈的一些任務，這個分支不做任何功能上的任務，完成之後將 release 分支再分別合併進 master/dev 分支，並在 master 提交上打上標籤 v1.0，這樣一個發佈階段的代碼操作就完成了
最後我們來看發佈之後的目前的日誌記錄情況，如圖 4.5 所示，這裏可以將沒有用的分支 hotfix、release、feature 均刪除了，可以看出我們的常駐分支就 master/dev，最下面的 feature 表示仍在開發中。
gitflow 工作流是目前比較很成熟的方案，它的優點有：
1、發佈迭代流程更順暢 2、使得代碼有了更加嚴謹的項目結構，方便定位排查問題
大型的項目 / 迭代速度快的推薦使用這種工作流程！
5.Forking 工作流
最後介紹一種開源項目常用的工作流 ——Forking 工作流，介紹之前首先需要了解什麼是 fork 操作，如圖 5.1 所示
fork 操作是在個人遠程倉庫新建一份目標遠程倉庫的拷貝，操作很簡單，比如 github 上在項目的主頁點擊 fork 按鈕即可。
明白了 fork 操作之後，我們來看下 forking 工作流的流程，如圖 5.2 所示：
首先開發者 A 擁有一個遠端倉庫，這時候有一個開發者 C 也想參與 A 的這個項目的開發工作，那他就可以 fork 一份 A 的這個倉庫，之後在 c 的個人倉庫裏就有了這份代碼庫，後續開發者 C 就可以在自己的這個項目裏進行開發工作，c 在完成了某個功能的實現之後，可以給 A 的倉庫發一個 PR 請求，這時候會通知到開發者 A 有新的 PR，A 如果有問題可以直接在這個 PR 裏提，開發者 C 可以進行進一步的修改，最後 A 通過了 C 的這份 PR 請求，就會將 C 的代碼合併進 A 的倉庫，這樣就完成了 A / 代碼庫新特性的開發。同時如果有其他開發者對 A 的項目有興趣也會進行相同的操作。
這裏注意到 開發者 B/C 並不是 A 代碼庫的開發人員，而是第三方開發者，所以這種工作流主要用於開源項目！
6. 總結
最後回顧下這幾種 git 工作流，集中式工作流可以說是 git 工作流的基礎，初學者可以無縫地從 svn 的模式切換到 git 的模式；功能分支工作流在集中式的基礎上又引入了功能分支，靈活地利用了 git 的分支特性，功能分離 / PR 優化了日常工作的效率；gitflow 工作流則是爲大型項目的迭代過程服務的，指定了一個嚴格的分支模型，使得迭代流程更加順暢；forking 工作流則是開源項目的首選，想要爲開源項目做貢獻就必須要懂得這種工作流！
當然，以上描述的這些工作流並不是實際工作中 git 使用的準則，這只是一些推薦的使用方式，在具體的項目研發過程中，我們需要結合項目以及團隊現狀作出取捨，總結出適合自己團隊的工作流，才能讓 git 更好地爲我們服務！
本文由 Readfog 進行 AMP 轉碼，版權歸原作者所有。
來源：https://mp.weixin.qq.com/s/VNRnx7fQ0Zy3LFe8XkKjAg