正常的Git管理流程

一、前言

Git是目前流行的版本管理工具，大家應該都使用過。雖然Git能為我們的項目管理提供極大的幫助，但是如果使用不當也會造成一些不必要的麻煩，特别是在多人協作的情況下。本文将講述我們在項目開發中使用的正常Git管理流程。

歡迎大家關注微信公衆号：Code滿滿

二、Git正常管理流程

1、常用的開發分支

• master 分支 : 主分支，不輕易改動，主要做正式發版使用，一般發版的包都從 master 分支中建構
• pre-release 分支 : 預釋出分支，是在正式發版前的測試使用分支，測試使用的包都從此處建構，測試完成後合并到 master 分支進行發版
• developer 分支 : 開發分支，每個版本的所有需求開發所在分支
• feature 分支 : 具體的需求開發分支，因為開發大都是團隊協作，開發成員負責自己的需求開發時，一般建議從 developer 分支中重新拉一條分支出來，作為成員自己的開發分支，最後再合并到 developer 分支中，是以 feature 分支一般會有多個
• hotfix 分支 : 緊急修複分支，如果線上版本遇到bug，則一般建議從 master 分支拉出一條分支，作為緊急修複分支，在 hotfix 測試沒有問題後，合并到 master 進行緊急發版

2、常用的Git管理流程

從上述常用分支介紹中，我們可以大緻了解團隊開發時的Git管理流程，此處我們再詳細介紹一下常用的管理流程。

Step 1 : 項目建立 master 分支。

Step 2 : 從 master 分支中拉出一條 developer 分支，作為所有的開發需求的彙總分支。

Step 3 : 進行具體的需求開發時，每位開發成員從 developer 分支中拉出一條分支，作為自己的 feature 分支進行具體的需求開發。

Step 4 : 開發完成後的 feature 合并到 developer。

Step 5 : 所有的需求都開發完成後，從 developer 分支中拉出一條 pre-release 分支，提供給 QA 進行測試。不過，有時為了效率，pre-release 分支可能會被省略，直接使用 developer 分支代替。但是如果項目開發時會出現交叉開發，那麼個人認為 pre-release 分支的存在還是很重要的。例如本期版本需求還未測試完畢，進行發版，下一期需求就要進行開發，則此時 developer 分支中可能就會混入下期需求代碼，那麼 pre-release 分支的存在就很有必要了。

Step 6 : 測試完成後，pre-release 分支合并到 master 分支進行發版，并且每次發版都需要打标簽，友善後續對曆史版本複盤。

Step 7 : 如果線上版本出現緊急bug，則從 master 分支拉出一條 hotfix 分支，對 bug 進行緊急修複，測試完成後将 hotfix 分支合并到 master 進行緊急發版，同時也需合并到 developer 分支。

PS : 所有的遠端分支合并，個人建議最好通過 Pull Request (即PR) 來進行。 例如我們要将自己的 feature 分支合并到遠端的 developer 分支，可以首先建立一個 PR，然後讓其他成員簡單的 review 代碼的改動，其他同僚 approve 後再合并到 developer。使用此種方式，能更有效的追蹤代碼的改動。

三、必須知道的Git常識

1、Git小常識

Git的三個區域

• 工作區 : 目前的工作區域
• 暫存區 : 被 git add 後的檔案所在區域
• 曆史記錄區 : 已送出曆史，git commit 後的送出檔案所在區域

Git的三種狀态

• 已修改 (modified) : 表示修改了檔案，但還沒儲存到本地倉庫中
• 已暫存 (staged) : 表示對一個已修改檔案的目前版本做了标記，使之包含在下次送出的暫存區中
• 已送出 (committed) : 表示資料已經安全地儲存在本地倉庫中

2、Git基本指令

git init : 初始化倉庫

在目前目錄建立一個Git倉庫，如果需要在指定目錄建立可以使用 git init [目錄]

git add : 添加檔案到暫存區

• git add [file1] [file2] ... : 将指定檔案添加到暫存區。
• git add [dir] : 将指定目錄添加到暫存區。
• git add . : Git 1.x版本時，将新檔案 (new) 和被修改 (modified) 檔案添加到暫存區，不包括被删除 (deleted) 檔案；在Git 2.x版本時，被删除檔案也會被添加到暫存區域。
• git add -u (git add --update的縮寫) : 将被修改 (modified) 和被删除 (deleted) 檔案添加到暫存區，不包括新檔案 (new)。
• git add -A (git add --all的縮寫): 送出所有變化，是 add . 與 add -u 的合集。

git commit : 将暫存區内容送出到本地倉庫中

• git commit -m [message] : 将暫存區内容送出到本地倉庫中，message 是本次送出的描述資訊
• git commit [file1] [file2] ... -m [message] : 将指定檔案送出到本地倉庫中
• git commit -a : -a 參數設定修改檔案後不需要執行 git add 指令，直接來送出
• git commit -am [message] : -a 參數設定修改檔案後不需要執行 git add 指令，直接來送出

git reset : 版本回退

git reset 的常用指令格式：git reset [--mixed | --soft | --hard | --merge | --keep] [HEAD]，預設是--mixed。

• HEAD 說明 HEAD 是目前分支版本頂端的别名，指向我們在目前分支的最近一次送出。例如下面一共進行了A、B、C三次送出，則 HEAD 指向 C。

[commit A]--->[commit B]--->[commit C]                                 

• 三種常用模式

--mixed : HEAD 指向指定 commit，暫存區回退到指定 commit 版本，工作區不變。

[commit A]--->[commit B]--->[commit C]---->[commit D]

小例子：看上述例子，共有 A、B、C、D 四個 commit，D 是最近一次送出，則 HEAD 指向 D。此時使用 git reset --mixed [commit B] 進行版本回退，則 HEAD 指向 B，暫存區回退到 B 版本，而 C、D 的 commit 内容會被回撤到工作區（即未被 git add 的狀态）。

--soft : HEAD 指向指定 commit，指定 commit 及之後的 commit 的内容被回撤到暫存區，工作區保持不變。

小例子：還是看上述例子，共有 A、B、C、D 四個 commit，D 是最近一次送出，則 HEAD 指向 D。此時使用 git reset --soft [commit B] 進行版本回退，則 HEAD 指向 B，而 C、D 送出的内容則回撤到暫存區中（即已 git add 但未 git commit 狀态）， C、D 的 commit 記錄會被擦除，工作區中的内容不會發生改變。

--hard : 重置暫存區與工作區，回退到指定的 commit 版本。

小例子：還是看上述例子，共有 A、B、C、D 四個 commit，D 是最近一次送出，則 HEAD 指向 D。此時使用 git reset --hard [commit B] 進行版本回退，則 HEAD 指向 B，暫存區回退到 B 版本，工作區回退到 B 版本， C、D 的 commit 内容被丢棄。

另外還有 --keep 與 --merge 兩種模式，但是不常用，此處不就不再詳述。

常見使用

1. HEAD 與 HEAD~0 表示目前版本
2. HEAD^ 與 HEAD~1 表示上一個版本
3. HEAD^^ 與 HEAD~2 表示上上個版本
4. HEAD^^^ 與 HEAD~3 表示上上上個版本
5. 以此類推...

git reset [模式] HEAD~1，表示回退到上個版本，或者我們也可以使用 git reset [模式] [commit id] 來回退到指定的 commit 版本。

3、Git分支管理

• git branch [branchname] : 以目前分支為模闆，建立新分支
• git branch -d [branchname] : 删除指定分支
• git checkout [branchname] : 切換到指定分支我一
• git checkout -b [branchname] : 建立分支，切換到該分支
• git merge [branchname] : 将指定分支合并到目前分支
• git merge --no-ff [branchname] : 關閉 fast-forward 模式，将指定分支合并到目前分支，與 git merge [branchname] 的差別是 git merge --no-ff [branchname] 合并時會建立一個 merge 的 commit，保留原來的分支 commit 曆史，一般推薦使用此種合并方式

master分支：[master-commit1]--->[master-commit2]

hotfix分支：[hotfix-commit3]--->[hotfix-commit4]

小例子：如上所示，目前我們在 master 分支，共進行了兩次 commit；此外還有一個以 master 分支為模闆建立的 hotfix 分支，共進行了兩次 commit。

方式一： 我們使用 git merge hotfix 合并 hotfix 到 master 分支上，此時 hotfix 的 commit 記錄會完全合并到 master 分支上，那麼 master 分支上的 commit 記錄為 [master-commit1]--->[master-commit2]--->[hotfix-commit3]--->[hotfix-commit4]，如下圖左側的圖，master 的分支曆史被擾亂。這時我們使用 git reset --hard HEAD^ 進行版本回退，則 master 會回退到 hotfix-commit3 版本。

方式二： 我們使用 git merge --no-ff hotfix 合并 hotfix 到 master 分支上，master 分支的 commit 曆史會被保留，如下圖右側圖。此時使用 git reset --hard HEAD^ 進行版本回退，則 master 會回退到 master-commit2

4、Git遠端管理

• git clone [url] : 克隆項目
• git pull [遠端主機名] [遠端分支名]:[本地分支名] : 拉取指定遠端分支與本地分支合并

小例子：

git pull origin master:test 将遠端的 master 分支拉下來與本地的 test 分支合并git pull origin master 如果是将遠端分支與目前分支合并，則可以省略本地分支名，這裡的意思是将遠端的 master 分支與本地分支合并

• git push [遠端主機名] [本地分支名]:[遠端分支名] : 推送指定本地分支到遠端并合并，如果遠端分支不存在，則會建立遠端分支

git push origin test:master 将本地的 test 分支推送到遠端 master 分支并合并；如果遠端 master 分支不存在，則會在遠端建立一個 master 分支git push origin mater 如果本地分支名與遠端分支名相同，則可以省略遠端分支名

• git push origin --delete [遠端分支名] : 删除指定的遠端分支
• git tag -l : 顯示已有标簽
• git tag [tagname] : 建立标簽
• git push origin [tagname] : 将本地标簽推送到遠端

如果本文對你有幫助，就關注一下微信公衆号：Code滿滿 ！