你應該懂 Git Workflow：Git Flow

來來來，要上線了，把不須要上線的功能都註釋掉。

這個操做讓人有點難以想象。

---

本來我覺得，程序員應該都會用 Git！但是，我發現我錯了。

Git

Git 是用來作版本管理的，在使用以前，你可能須要先安裝它。但一般狀況下是不須要的，由於它真的過重要了，因此大部分的操做系統默認都已經安裝過了。

Repository

對於 Git 倉庫，有如下兩種類型：

• 本地倉庫，能夠理解爲保存在某臺主機上不共享的 Git 倉庫

本地倉庫有太多的限制，好比說：沒法遠程訪問、多人協做等。因此，一般狀況下咱們都是直接建立遠程倉庫的。

• 遠程倉庫，保存在遠程服務器上的 Git 倉庫

對於遠程倉庫，咱們能夠本身搭建 Git 服務器，也可使用諸如：GitHub（收費）、GitLab、BitBucket 等現成的服務。我的比較推薦使用 GitLab。

一點思考

我想，一些程序員不使用版本管理工具（Git）來管理代碼確定是有緣由的，好比說：

• 一我的開發必有必要；
• 感受沒什麼用，用不用都沒什麼影響。

有句話好像是這樣說的：「失敗的緣由各類各樣，但成功的緣由卻大體相同」。咱們能夠思考一下下面的問題：

• 若你的代碼只是保存在電腦上，要是須要在家修改代碼怎麼辦？你不見得去哪都帶着電腦吧！萬一你用的電腦是臺式機，那就尷尬了。

仔細想一想，你可能就會以爲確實是那麼回事，因此你就在 GitLab 上建立了一個私有的倉庫。這是 Git 解決的第一個問題：遠程協做

• 在兩週的迭代後，咱們發佈了新的版本，卻發現新的版本存在 Bug，老闆要求回到上一個穩定版本。

這時候你可能就懵了，由於你已經徹底不記得上一個版本是什麼樣子了。這是 Git 解決的第二個問題：版本控制

• 你可能會還會遇到這樣的狀況，團隊的開發人員在 master 分支上開發的好好的，卻接到客服或運營的 Bug 反饋，這時候你要改 Bug 併發布，可是新開發的功能還沒開發完。

這時候，你會發現這個問題解決起來卻有點麻煩，你可能就須要對你們說：「來來來，要上線了，把不須要上線的功能都註釋掉」。這是 Git 要解決的第三個問題：分支管理

這裏只介紹 Git 解決的三個主要問題，固然 Git 的功能遠不止這些，但這三點是必需要搞明白的。

Workflow

分支管理是 Git 的強大功能，在實際的開發中能解決不少問題。而每一個人對分支管理的理解是不一樣，也就會產生不少種分支管理方法。好比說：有的程序員只使用一個 Master 分支，開發、測試、發佈、維護（Bug 修復）都在 Master 分支上完成。這樣作一定會產生不少問題。

分支管理的主要目的是：知足整個研發過程當中（開發、測試、發佈、維護），代碼的版本控制。這就須要咱們在作分支管理的時候，去決策須要使用多少分支，每一個分支分別須要作什麼事情，以及何時建立/合併分支。而這些就是 Git 的工做流，是咱們在整個研發過程當中使用 Git 來管理代碼的流程和規範。

對於 Git 工做流，經常使用的主要有三種，如：

• Git Flow
• GitLab Flow
• GitHub Flow

Git Flow 就是咱們接下來要說明的。

Branch

首先這種工做流會用到如下幾種分支：

• master，主分支，建立 Repository 時默認會生成一個 master 分支。一般狀況下 master 分支是受保護的（Protected）。master 分支保存的是穩定的已發佈到線上的代碼，會使用 tag 來記錄發佈的版本。master 分支是不容許提交代碼的，只能將代碼合併（merge）到 master。
• develop，開發分支，從 master 建立。須要注意的是，一般狀況下，咱們只在 develop 上開發一些基礎的代碼。而對於一些新的功能，咱們是不會在 develop 上開發的，由於你不能肯定這些是否須要上線（或者說沒法肯定在哪次迭代上線）。
• feature，功能分支，從 develop 建立。feature 分支是用來開發新功能的，一般狀況下新功能開發完畢後會合併的 develop。
• release，發佈分支 從 develop 建立。當一次迭代的功能開發並自測完成後，就能夠建立發佈分支。該分支一般用於測試，咱們不能在該分支上完成除 Bug 修復外的其餘工做。測試完成後，咱們須要將 release 分支合併到 master 進行發佈。發佈完成後在 master 打上 tag 記錄這次發佈的版本，並將 hotfix 合併到 develop。
• hotfix，修復分支，從 master 建立。當咱們發現線上 Bug 時，會從 master 分支上對應的 tag 處建立新的 hotfix 分支，用來修復 bug。一般狀況下，緊急修復的發佈相對簡單，在 Bug 修復並測試完成後，可直接合併到 master 進行發佈。發佈完成後在 master 打上 tag 記錄這次發佈的版本，並將 hotfix 合併到 develop。

Workflow

對於工做流，用圖來表示會更容易理解，以下圖：

圖中就是咱們使用 Git Flow 工做時的流程。很明顯，Git Flow 須要用到不少分支，這也是不少開發者放棄它的理由。對於 Git Workflow 還有其餘的選擇，好比：GitLab Flow 和 GitHub Flow。固然你也能夠根據實際的業務場景使用本身的工做流，方式不一樣，但都是爲了一樣的目的。