來來來，要上線了，把不需要上線的功能都注釋掉。
這個操作讓人有點不可思議。
原本我以為，程序員應該都會用 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。當然你也可以根據實際的業務場景使用自己的工作流，方式不同，但都是為了同樣的目的。