你應該掌握的git操作

前言

目前來說，版本控制主要分爲：集中式版本控制（Centralized Version Control Systems，簡稱 CVCS）和分佈式版本控制，（Distributed Version Control System，簡稱 DVCS）。

CVCS的代表主要有CVS、SVN 以及 Perforce 等； 

DVCS主要有 Git、Mercurial、Bazaar 以及 Darcs 等。我們平時比較常用的就是SVN和Git。

集中式與分佈式爭議很多，各有特色，這裏就多說了。目前公司內部2種多有使用。

如想了解SVN的簡單使用，可以查看：SVN的介紹與使用流程  。接下就開始介紹Git的簡單操作使用。以下主要對官方文檔以及其他文檔的總結，如果需要查看詳細官方文檔，可以跳轉到這裏：https://git-scm.com/book/zh/v2

要知道的概念

工作區域的三種狀態

Git 有三種狀態，你的文件可能處於其中之一：已提交（committed）、已修改（modified）和已暫存（staged）。由此引入 Git 項目的三個工作區域的概念：Git 倉庫、工作目錄以及暫存區域，如下圖所示。

 

Git 倉庫：是 Git 用來保存項目的元數據和對象數據庫的地方。 這其它計算機克隆倉庫時，拷貝的就是這裏的數據。

工作目錄：是對項目的某個版本獨立提取出來的內容。這些從 Git 倉庫提取出來的文件，放在磁盤上供你使用或修改。

暫存區域：是一個文件，保存了下次將提交的文件列表信息，一般在 Git 倉庫目錄中。 有時候也被稱作“索引“，不過一般說法還是叫暫存區域。

三種工作區域和三種文件狀態關係

如果 Git 目錄中保存着的特定版本文件，就屬於已提交狀態； 如果作了修改並已放入暫存區域，就屬於已暫存狀態； 如果自上次取出到工作目錄，作了修改但還沒有放到暫存區域，就是已修改狀態。

Git 的基本工作流程如下：

其實上面的流程圖，也是在實際工作中的大體流程，簡介的概括如下：

1. 在工作目錄中修改文件。
2. 暫存文件，將文件的快照放入暫存區域；
3. 提交更新，找到暫存區域的文件，將快照永久性存儲到 Git 倉庫目錄。

Git 保證完整性

Git 中所有數據在存儲前都計算校驗和，然後以校驗和來引用。 這意味着不可能在 Git 不知情時更改任何文件內容或目錄內容。  若你在傳送過程中丟失信息或損壞文件，Git 就能發現。

用以計算校驗和的機制叫做 SHA-1 散列（hash，哈希）。這是一個由 40 個十六進制字符（0-9 和 a-f）組成字符串，基於 Git 中文件的內容或目錄結構計算出來；如：

 

24b9da6552252987aa493b52f8696cd6d3b00373

Git 數據庫中保存的信息都是以文件內容的哈希值來索引，即commit id ，而不是文件名。如：

git show 24b9da6552

這裏指定了commit id，則相當於指定了這次提交的記錄。而且不一定寫入整個id，一般需要6-8位則可以確定。

文件的生命週期

工作目錄下的每一個文件都不外乎這兩種狀態：已跟蹤或未跟蹤。

已跟蹤的文件：是指那些被納入了版本控制的文件，在上一次快照中有它們的記錄，在工作一段時間後，它們的狀態可能處於未修改，已修改或已放入暫存區。 初次克隆某個倉庫的時候，工作目錄中的所有文件都屬於已跟蹤文件，並處於未修改狀態。

未跟蹤文件：工作目錄中除已跟蹤文件以外的所有其它文件都屬於未跟蹤文件，它們既不存在於上次快照的記錄中，也沒有放入暫存區。 

編輯過某些文件之後，由於自上次提交後你對它們做了修改，Git 將它們標記爲已修改文件。 我們逐步將這些修改過的文件放入暫存區，然後提交所有暫存了的修改，如此反覆。所以使用 Git 時文件的生命週期如下：

 

可以通過git status 查看文件的當前狀態，簡單介紹下每個狀態：

1.Untracked：未納入版本庫中的文件，即未跟蹤；

2.Unmodified：已納入版本庫的文件，未做修改；

3.Modified：已納入版本庫的文件，已修改；

4.Staged：添加到緩存區的文件；

整體的流程大致是這樣子，如果沒看懂也沒事。現有個印象，學習完實踐之後，就會覺得so easy！接下里就介紹流程中會使用到的命令。

Git指令的使用

幫助文檔

若你使用 Git 時需要獲取幫助，有四種方法可以找到 Git 命令的使用手冊：

$git help
$ git help <verb>
$ git <verb> --help
$ man git-<verb>    //man是Linux的查詢指令，試了下該指令在git的控制端沒有效果，需在Linux服務器 

倉庫的初始化  

git init

該命令將創建一個名爲 .git 的隱藏文件，這個子目錄含有你初始化的 Git 倉庫中所有的必須文件，這些文件是 Git 倉庫的骨幹。倉庫初始化之後，才能執行其他命令，不然會報錯。

git clone

如果直接從某個遠程倉庫拷貝，那麼就可以使用該命令。比如在GitHub想拷貝一個demo，如：

$ git clone https://github.com/libgit2/libgit2

命令格式是 ：git clone [url]

如果想拷貝在指定的目錄：git clone [url]  [pathName]

添加/暫存 文件

git add 

 作用是跟蹤的新文件、已修改的文件添加到暫存區。該命令是對內容快照的緩存，不是針對文件（與SVN不同），所以每次修改多需要執行該指令才能將此次修改添加到暫存區。

git add -u : 提交被修改(modified)和被刪除(deleted)文件，不包括新文件(new)。
git add .  ：提交新文件(new)和被修改(modified)文件，不包括被刪除(deleted)文件。
git add -A : 提交所有變化，包括以上2種。

如果需要選擇性暫存文件，那麼可以將這個文件連綴在後面，用空格隔開：

git add <file1> <file2> <file3>

 

查看文件狀態

git status

顯示工作目錄的狀態，不帶參數執行，輸出內容很詳細。並且根據文件是否暫存，會預示下一步的指令操作。

如果想簡潔一點，那麼加個--short （-s）參數：git status -s

 

提交文件

git commit                  

將文件添加到暫存區之後，就可以開始提交了。每次提交之前，一般先再次檢查文件狀態git status，看是否還有文件未添加到暫存區。一般執行提交是：

git commit -m <commit log>  使用-m 參數 ，附帶簡明提交說明信息。

如果直接執行git commit，啓動文本編輯器以便輸入本次提交的說明。

問題：是不是所有的修改多必須git add後才能提交？

並不是，Git也提供跳過暫存區提交，如果覺得煩瑣，可以直接不執行git add提交，直接執行以下指令：  

git commit -a -m <commit log>  

但是，只針對已經跟蹤過的文件，如果是新建一個文件，是不會提交的。所以我本人還是比較少用。

 

移除文件

git rm 

從git中將已跟蹤的文件從工作目錄、暫存區移除，注意是已跟蹤的。如果該文件又是已修改的，可以使用參數 -f 強制刪除。

如果移除未跟蹤的文件，或者只在工作目錄移除，在暫存區繼續保留，那麼可以執行：

rm  <file>  

如果只移除暫存區的文件，但不移除工作目錄文件，如.gitignore 文件，可以使用使用 --cached 選項（（Git 1.6.1 及更高版本還允許使用 git diff --staged，後面還會用到）

git rm --cached  <file> 

移動文件

git mv

從git中將已跟蹤的文件重新命名，或者將文件從一個目錄移動到另一個目錄。如：

git mv README.md  README     // 將README.md 重新命名 README
git mv README    test/       //將 README文件 移動到test目錄下

其實，git mv，相當於執行以下三條命令：

$ mv README.md README
$ git rm README.md
$ git add README

他們的效果是一樣的，git一樣會記錄這是一次改名。

查看文件差異

git diff 

git status 命令輸出的只是大體的差異，要知道具體修改了什麼地方，可以用 git diff 命令。

如果不加參數執行，那麼顯示差異是當前目錄下所有未暫存的文件，比較的是工作目錄中文件和暫存區域快照之間的差異。

 

如果查看暫存區與倉庫之間的差異，還是用到 --cached 選項:

git diff  --cached

所以這2條命令是有區別的，有時你執行git diff 什麼也沒有，那是因爲你已經添加在暫存區了，嘎嘎！

 

如果要查看指定的文件差異，那麼後面直接添加文件路徑即可：

git diff README.md  

如果要查看2個指定版本的差異，那嗎後面可以添加這個2版的commit id，還有添加路徑，查看指定的文件：

git diff <commitId_1> <commitId_2>  [path]

查看歷史記錄 

git log  

查詢記錄最常用到，而且參數也非常多：

git log [<options>] [<since>..<until>] [[--] <path>...]

不加參數執行，會按提交時間列出所有的更新，最近一次更新排在最上面，列出每個提交的 SHA-1 校驗和、作者的名字和電子郵件地址、提交時間以及提交說明。

git reflog： 查看歷史提交記錄，包括你沒有更新的提交

有時歷史記錄那麼多，怎麼才能又快又精準找到呢？這裏有太多參數可以供選擇了：

 -p  用來詳細顯示每次提交的內容差異，顯示與git diff 類似。
--stat   用來簡略顯示每次提交的統計信息，
--pretty  使用其他格式顯示歷史提交信息。
比如：git log --pretty=oneline ：將每個提交放在一行顯示，查看的提交數很大時非常有用。可用的選項包括 short，medium，full，fuller ，email 和 format（後跟指定格式），展示的信息或多或少有些不同，自己可以動手實踐一下看看效果如何。

--graph   顯示 ASCII 圖形表示的分支合併歷史。一般結合oneline ，format使用時尤其有用，如查看分支提交記錄：

git log --graph --pretty=oneline --abbrev-commit   

-n  僅顯示最近的 n 條提交 ，其中的 n 可以是任何整數
--author 顯示指定作者的提交
--grep  僅顯示提交說明中含指定關鍵字的提交
--since / --after   僅顯示指定時間之後的提交，如：git log --since “1 day ago”
--until / --before    僅顯示指定時間之前的提交 如：git log --until “2018-2-1”
<path>  查看當前某些文件或目錄的提交
.....
其他選項可以通過 git log --help 查看

 

一般，以上這些選項多是可以組合使用，比如：如果要查看 Git 倉庫中，2018 年 1個月期間，jack 提交的歷史記錄，可以用下面的查詢命令：

 

git log --pretty=oneline    --author="jack" --since="2018-3-1" --until="2018-4-1"

 

撤銷修改

使用 git reset撤銷

git reset --hard   HEAD~：  將本地倉庫、暫存區、工作目錄恢復到上一個版本（所有的修改將會失去）

git reset --mixed HEAD~：將本地倉庫、暫存區恢復到上一個版本，工作目錄保存着修改

git reset --soft HEAD~：將本地倉庫、上一個版本，暫存區、工作目錄保存着修改

git reset HEAD~2 <path>： 帶文件路徑，默認是--mixed，只將暫存區，路徑path下的文件恢復到之前2個版本

git checkout -- <file>... ：  撤銷工作區中已修改的文件

git commit  --amend ：覆蓋上一次的提交。

比如還有文件未添加，或者需要重新修改提交信息，如：

$ git commit -m "initial commit"
$ git add README.md
$ git commit --amend  -m“initial commit +1”

最終只會有一個提交 ，第二次提交將代替第一次提交的結果。

 

遠程倉庫使用

 

遠程倉庫是指託管在因特網或其他網絡中的項目的版本庫。其常使用的指令有如下：

git clone <url>   克隆遠程倉庫到本地
git remote  列出每個遠程倉庫的簡短名字
git remote -v    列出每個遠程倉庫的簡短名字與其對應的 URL
git remote show [remote-name]   查看某個遠程倉庫的詳細信息
git remote rename [old name] [new name]  重命名遠程倉庫
git remote rm [remote-name]   移除某個遠程倉庫
git remote add <shortname> <url>  添加一個遠程倉庫
git fetch [remote-name]  從遠程倉庫數據拉取最新到本地，但不自動合併本地的修改
git  pull   [remote-name] [branch-name]  把遠程倉庫數據拉到本地，並自行合併
git pull 的魔法經常令人困惑所以通常單獨顯式地使用 fetch 與 merge 命令會更好一些。
git  push [remote-name] [branch-name]    把本地代碼推送到遠程倉庫，一般先執行git pull、在執行git push  確保代碼是最新的，不然會被拒絕。

***如果git pull提示“no tracking information”，則說明本地分支和遠程分支的鏈接關係沒有創建，用命令：

git branch --set-upstream branch-name origin/branch-name

 

打標籤

比較常用在發佈版本的時候，比如當前軟件第一次發佈，那麼就可以在發佈的版本上打上“v1.0”標籤。無論在什麼時候，取出“v1.0”標籤，對應的一定是第一次發佈的版本，他是不會變，與分支不同。

git tag   <tagname>    給版本添加標籤

git tag        按字母順序直觀列出所有標籤
git tag -l <tagname>   簡潔列出某個標籤
git show <tagname>   詳細列出某個標籤，顯示包括打標籤者的信息、打標籤的日期時間、附註信息，然後顯示具體的提交信息。

 

git tag -a <tagname>  <commit id>  給之前的版本添加標籤
git tag -d <tagname>    可以刪除一個本地標籤；
git push origin <tagname>  將某個本地標籤推到遠程，共享標籤
git push origin --tags           將所有的本地分支推到遠程；
git checkout -b [branchname] [tagname]     檢出標籤，在特定的標籤上創建一個新分支
git push origin :refs/tags/<tagname>  刪除某個遠程的標籤，要刪除遠程標籤，必須要先刪除本地

標籤不是按時間順序列出，而是按字母排序的

Git 使用兩種主要類型的標籤：

附註標籤（annotated）：附註標籤是存儲在 Git 數據庫中的一個完整對象。 它們是可以被校驗的；其中包含打標籤者的名字、電子郵件地址、日期時間；還有一個標籤信息；並且可以使用 GNU Privacy Guard （GPG）簽名與驗證。 通常建議創建附註標籤，這樣你可以擁有以上所有信息。如：

git tag -a v0.1  -m "version 0.1 released"   其中，用-a指定標籤名， -m指定說明文字，還可以使用 -s 給私鑰簽名

輕量標籤（lightweight）：很像一個不會改變的分支，本質上是將提交校驗和存儲到一個文件中 ， 沒有保存任何其他信息，只是一個特定提交的引用。如果只是想用一個臨時的標籤，則一般使用輕量標籤。不需要使用 -a、-s 或 -m 選項，只需要提供標籤名字，如：

git tag  v1.0    給版本添加標籤爲v1.0

 

分支（分支是重點，建議查看官方文檔，非常詳細易懂）

 Git 的分支模型稱爲它的“必殺技特性”，也正因爲這一特性，使得 Git 從衆多版本控制系統中脫穎而出。 Git 處理分支的方式可謂是難以置信的輕量，創建新分支這一操作幾乎能在瞬間完成，並且在不同分支之間的切換操作也是一樣便捷。 （分支是重點，建議查看官方文檔，非常詳細易懂）

git branch   查看分支（當前工作分支前面會標一個*號）
git branch -v  查看每一個分支的最後一次提交
git branch -vv  查看每一個分支的詳細信息，如每一個分支正在跟蹤哪個遠程分支與本地分支是否是領先、落後
git show-branch   詳細查看的分支記錄

git  branch <branchname>       創建分支， HEAD 的特殊指針也會移到當前分支
git checkout  <branchname>   切換分支
git checkout  -b <branchname> 創建分支，並切換到該分支，即合併上面2步  

git mergr  <branchname> ：合併分支，如果需要合併到master分支，那麼需要先切換到master分支，再進行整合 (該合併分支，是Fast forward模式，在服務器中是沒有記錄的)
git merge --no-ff -m "merge with no-ff" <branchname>     合併分支（禁用Fast forward模式，能看到分支記錄）

git branch --merged   查看已經合併到當前分支的分支。 
git branch --no-merged  查看尚未合併到當前分支的分支。 
git branch -d  <branchname>        刪除已經合併的分支
git branch -D  <branchname>      可強制刪除尚未合併的分支 
git push origin --delete serverfix    刪除某個遠程分支

git checkout -m <branchname>  將本地的修改加入到新的分支上

git checkout -b branch-name  origin/branch-name 在本地創建和遠程分支對應的分支，本地和遠程分支的名稱最好一致

在合併的時候，你應該注意到了"快進（fast-forward）"這個詞。 由於當前 master 分支所指向的提交是你當前提交的直接上游，所以 Git 只是簡單的將指針向前移動。 換句話說，當你試圖合併兩個分支時，如果順着一個分支走下去能夠到達另一個分支，那麼 Git 在合併兩者的時候，只會簡單的將指針向前推進（指針右移），因爲這種情況下的合併操作沒有需要解決的分歧——這就叫做 “快進（fast-forward）”。

 

儲藏與清除

問題：如果在其他分支開發，突然有個更緊急的bug需要修復，怎麼辦？
此時只要切回master分支，繼續其他分支開發就可以。但是，要留意你的工作目錄和暫存區裏那些還沒有被提交的修改，它可能會和你即將檢出的分支產生衝突從而阻止 Git 切換到該分支。 最好的方法是，在你切換分支之前，保持好一個乾淨的狀態。 這裏有2個方向：將修改的文件儲藏起來；將修改的文件清除。

 

 

儲藏文件

指的是在當前分支先將目前修改的文件保存起來（保存進度（stashing）），完成任務之後再回到該分支恢復進度（apply）。那麼相關的指令有如下：
git stash  將當前工作目錄已跟蹤的文件儲藏起來，如同時儲藏將未跟蹤的文件，可以添加參數--include-untracked （-u ）
git stash list  查看儲藏列表
git stash apply   將最近一次儲藏恢復到工作目錄，但是恢復後，儲藏內容並不刪除
git stash apply stash@{<num>}   恢復某個指定的緩存
git stash drop   stash@{<num>}   將某個緩存從列表中移除
git stash pop   恢復最近一次緩存，並立即從列表上移除

 

 

git stash branch <branchname>  從儲藏中創建一個分支

 

清除文件

對於工作目錄中一些工作或文件，你想做的也許不是儲藏而是移除，那麼就有以下指令：
git clean    移除未跟蹤文件（不包括忽略的文件），恢復不了
git clean  -d -f  移除工作目錄中所有未追蹤的文件以及空的子目錄
git clean  -d -x    移除未跟蹤文件（包括忽略的文件）
git clean  -d  -n  預示將要移除什麼文件，但還未移除

git clean   -i      交互式預示將要移除什麼文件，但還未移除

git stash --all   將移除每一樣東西並存放在棧中

搜索

git grep <tag>   搜索當前目錄下的字符串
git grep -n <tag>  將搜索的字符串添加行號顯示
git grep --count  <tag>  只顯示當期目錄匹配的個數
git grep -p <tag>  匹配字符串是屬於哪一個方法或者函數，後面還可以添加文件類型，如git grep -p gmtime_r *.c
git log -S[tag]    顯示新增和刪除該字符串的提交   如：git log -SZLIB_BUF_MAX --oneline
git log -L   查看函數或者一行的提交記錄，如：git log -L :git_deflate_bound:zlib.c
 

Git的配置

Git 自帶一個 git config 的工具來幫助設置控制 Git 外觀和行爲的配置變量。 這些變量存儲在三個不同的位置：

 

• /etc/gitconfig 文件: 包含系統上每一個用戶及他們倉庫的通用配置。 如果使用帶有 --system 選項的 git config 時，它會從此文件讀寫配置變量。
• ~/.gitconfig 或 ~/.config/git/config 文件：只針對當前用戶。 可以傳遞 --global 選項讓 Git 讀寫此文件。
• 當前使用倉庫的 Git 目錄中的 config 文件（就是 .git/config）：針對該倉庫。

每一個級別覆蓋上一級別的配置，所以 .git/config 的配置變量會覆蓋 /etc/gitconfig 中的配置變量。

要想獲得 config 命令的手冊，執行 ：git help config  

配置用戶信息

安裝完之後，我們一般多是需要配置自己的郵箱與用戶名，那麼就可以：

$ git config --global user.name  John Doe
$ git config --global user.email   [email protected]

這裏使用了 --global參數，那麼所有的倉庫都將使用該信息。如果你想對特定的倉庫使用不同的信息，那麼在該倉庫目錄下執行沒有帶 --global 參數的命令。
 

配置編輯器

一般Git默認使用的是Vim，這也是我們經常使用的編輯器。但如果你想使用不同的文本編輯器，例如 Emacs，可以這樣做：

$ git config --global core.editor emacs

配置簡寫

有些指令已經練到信手拈來，但無奈指令太長了，寫太多感覺會走火入魔。還好Git可以將指令設置別名，格式：

git config --global  alias.<別名> <指令名>   

 如： 

$ git config --global alias.co checkout
$ git config --global alias.br branch
$ git config --global alias.ci commit
$ git config --global alias.st status

將一些複雜的指令，也配置一下，如：

$ git config --global alias.unstage “reset HEAD --”

設置該別名之後，那麼以下2條命令是等同的：

$ git unstage fileA
$ git reset HEAD -- fileA

喪心病狂者還有這種操作：

git config --global alias.lg "log --color --graph --pretty=format:'%Cred%h%Creset -%C(yellow)%d%Creset %s %Cgreen(%cr) %C(bold blue)<%an>%Creset' --abbrev-commit"

原來git log是這樣子，現在變成這樣子了，簡直不要不要的。

如果哪一天，你太牛逼，牛逼到沒有朋友。想回到從前平淡的生活，刪除這些設置也是灰常容易的。找到配置文件，刪除這些別名即可。

最後你可以檢查你的配置，可以使用 ：

git config --list  ：命令來列出所有 Git 當時能找到的配置；
git config <key> ：檢查 Git 的某一項配置

忽略文件

在編譯過程中創建的臨時文件，或者不想納入版本控制的文件，就可以添加到名爲 .gitignore 的文件。一般git clone的倉庫是帶有這個文件的，如果沒有，可以自行創建：touch .gitignore。創建之後，建議將.gitignore提交，這樣以後就比較方便了。

文件 .gitignore 的格式規範如下：

 

• 所有空行或者以 ＃ 開頭的行都會被 Git 忽略。
• 可以使用標準的 glob 模式匹配。
• 匹配模式可以以（/）開頭防止遞歸。
• 匹配模式可以以（/）結尾指定目錄。
• 要忽略指定模式以外的文件或目錄，可以在模式前加上驚歎號（!）取反。

所謂的 glob 模式是指 shell 所使用的簡化了的正則表達式。 比如：星號（*）匹配零個或多個任意字符；[abc] 匹配任何一個列在方括號中的字符。使用Linux指令的，應該就比較熟悉了，這裏不介紹了。
所有不同開發的配置文件可以直接在線瀏覽：https://github.com/github/gitignore
一般拷貝過來直接用就可以了，當然也可以自己再添加
比如，一般在android下使用的忽略文件：

# Built application files
*.apk
*.ap_

# Files for the ART/Dalvik VM
*.dex

# Java class files
*.class

# Generated files
bin/
gen/
out/

# Gradle files
.gradle/
build/

# Local configuration file (sdk path, etc)
local.properties

# Proguard folder generated by Eclipse
proguard/

# Log Files
*.log

# Android Studio Navigation editor temp files
.navigation/

# Android Studio captures folder
captures/

# IntelliJ
*.iml
.idea/workspace.xml
.idea/tasks.xml
.idea/gradle.xml
.idea/assetWizardSettings.xml
.idea/dictionaries
.idea/libraries
.idea/caches

# Keystore files
# Uncomment the following line if you do not want to check your keystore files in.
#*.jks

# External native build folder generated in Android Studio 2.2 and later
.externalNativeBuild

# Google Services (e.g. APIs or Firebase)
google-services.json

# Freeline
freeline.py
freeline/
freeline_project_description.json

# fastlane
fastlane/report.xml
fastlane/Preview.html
fastlane/screenshots
fastlane/test_output
fastlane/readme.md

 

分支策略

在實際開發中，我們應該按照幾個基本原則進行分支管理：

首先，master分支應該是非常穩定的，也就是僅用來發布新版本，平時不能在上面幹活；

那在哪幹活呢？幹活都在dev分支上，也就是說，dev分支是不穩定的，到某個時候，比如1.0版本發佈時，再把dev分支合併到master上，在master分支發佈1.0版本；

你和你的小夥伴們每個人都在dev分支上幹活，每個人都有自己的分支，時不時地往dev分支上合併就可以了。

所以，團隊合作的分支看起來就像這樣：

 

如果你需要一個更加完美的分支策略，那麼這裏有個阿里巴巴分享的：

阿里巴巴的分支結構

 

 

分佈式工作流程

Git 的分佈式協作可以爲你的項目和團隊衍生出種種不同的工作流程，比較常見有以下3種： 

你可以選擇使用其中的某一種，或者將它們的特性混合搭配使用。

1.集中式工作流

一箇中心集線器，或者說倉庫，所有人將自己的工作與之同步。 若干個開發者則作爲節點，並且與其進行同步。這和 Subversion 中的概念一樣，這個模式也可以很好地運用到 Git 中。

 只需要搭建好一箇中心倉庫，並給開發團隊中的每個人推送數據的權限，就可以開展工作了。Git 不會讓用戶覆蓋彼此的修改。這種模式的工作流程的使用非常廣泛，因爲大多數人對其很熟悉也很習慣。

 

 

 

2.集成管理者工作流

 

 

這是 GitHub 和 GitLab 等集線器式（hub-based）工具最常用的工作流程。

如果要爲這個項目做貢獻，你需要從該項目克隆出一個自己的公開倉庫，然後將自己的修改推送上去。 接着你可以請求官方倉庫的維護者拉取更新合併到主項目。 維護者可以將你的倉庫作爲遠程倉庫添加進來，在本地測試你的變更，將其合併入他們的分支並推送回官方倉庫。 這一流程的工作方式如下所示：

• 項目維護者推送到主倉庫。
• 貢獻者克隆此倉庫，做出修改。
• 貢獻者將數據推送到自己的公開倉庫。
• 貢獻者給維護者發送郵件，請求拉取自己的更新。
• 維護者在自己本地的倉庫中，將貢獻者的倉庫加爲遠程倉庫併合並修改。
• 維護者將合併後的修改推送到主倉庫。

這麼做最主要的優點之一是你可以持續地工作，而主倉庫的維護者可以隨時拉取你的修改。 貢獻者不必等待維護者處理完提交的更新，每一方都可以按照自己節奏工作。
 

3.司令官與副官工作流

這種工作流程並不常用，只有當項目極爲龐雜，或者需要多級別管理時，纔會體現出優勢。例如著名的 Linux 內核項目。本人研究下了也搞不懂，這裏就不介紹，減少負擔。嘎嘎~

 

結語

好了，也是在學習中總結，也有很多不足的地方，總結不是很到位，請指出。

記得很早開始開始接觸，看文檔的時候，一開始就開始講一大堆理論，完全懵逼。因爲項目也沒有使用，沒堅持住。所以，一點心得就是，初學不需明白那些，只要知道git是個版本控制器就行，和SVN的區別也不需理會，但可以借鑑相同之處。之前項目沒有使用，學習過很快就忘了。現在一邊學習一邊應用，效率纔是最高的。使用過，才知道他是個什麼，以前那些原理也就恍然大悟了，可以舉一反三！即初學少研究，多實踐，最後事倍功半！