你應該懂 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。當然你也可以根據實際的業務場景使用自己的工作流，方式不同，但都是為了同樣的目的。