一、前言

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

歡迎大家關注微信公眾號：碼途有道

二、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 兩種模式，但是不常用，此處不就不再詳述。

常見使用
HEAD 與 HEAD~0 表示當前版本
HEAD^ 與 HEAD~1 表示上一個版本
HEAD^^ 與 HEAD~2 表示上上個版本
HEAD^^^ 與 HEAD~3 表示上上上個版本
以此類推…

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] : 將本地標簽推送到遠程

如果本文對你有幫助，就關注一下微信公眾號：碼途有道 ！

總結

以上是生活随笔為你收集整理的常规的Git管理流程的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。