一小時學會 ——Git
目錄
- 一、版本控制概要 工作區 暫存區 本地倉庫 遠端倉庫
- 二、Git安裝與配置
- 三、Git理論基礎
- 四、Git操作
- 4.1、建立工作目錄與常用指令
- 4.2、獲得GIT倉庫
- 4.3、GIT檔案操作
- 4.3.1、檔案4種狀態
- 4.3.2、檢視檔案狀態
- 4.3.3、新增檔案與目錄
- 4.3.4、移除檔案與目錄（撤銷add）
- 4.3.5、檢視檔案修改後的差異
- 4.3.6、簽出
- 4.3.6、忽略檔案
- 4.3.7、提交
- 4.3.8、日誌與歷史
- 4.3.9、檢視檔案列表
- 4.3.10、撤銷更新
- 4.3.11、刪除檔案
- 4.3.12、檔案操作小結
- 4.4、GIT分支
- 4.5、Git GUI 操作
- 4.6、IDE整合的Git客戶端
- 4.7、幫助與程式碼統計
- 五、遠端倉庫
- 六、作業與評分標準
- 七、資源與資料下載
- 八、視訊
最近要與部門同事一起做技術分享，我選擇了Git，因為Git 是一種在全球範圍都廣受歡迎的版本控制系統。在開發過程中，為了跟蹤程式碼，文件，專案等資訊中的變化，版本控制變得前所未有的重要。
一、版本控制概要 工作區 暫存區 本地倉庫 遠端倉庫
1.1、什麼是版本控制
版本控制（Revision control）是一種在開發的過程中用於管理我們對檔案、目錄或工程等內容的修改歷史，方便檢視更改歷史記錄，備份以便恢復以前的版本的軟體工程技術。
- 實現跨區域多人協同開發
- 追蹤和記載一個或者多個檔案的歷史記錄
- 組織和保護你的原始碼和文件
- 統計工作量
- 並行開發、提高開發效率
- 跟蹤記錄整個軟體的開發過程
- 減輕開發人員的負擔，節省時間，同時降低人為錯誤
簡單說就是用於管理多人協同開發專案的技術。
沒有進行版本控制或者版本控制本身缺乏正確的流程管理，在軟體開發過程中將會引入很多問題，如軟體程式碼的一致性、軟體內容的冗餘、軟體過程的事物性、軟體開發過程中的併發性、軟體原始碼的安全性，以及軟體的整合等問題。
1.2、常用術語
1)、倉庫（Repository）
受版本控制的所有檔案修訂歷史的共享資料庫
2)、工作空間（Workspace)
本地硬碟或Unix 使用者帳戶上編輯的檔案副本
3)、工作樹/區（Working tree）
工作區中包含了倉庫的工作檔案。您可以修改的內容和提交更改作為新的提交到倉庫。
4)、暫存區（Staging area）
暫存區是工作區用來提交更改（commit）前可以暫存工作區的變化。
5)、索引（Index）
索引是暫存區的另一種術語。
6)、簽入（Checkin）
將新版本複製回倉庫
7)、簽出（Checkout）
從倉庫中將檔案的最新修訂版本複製到工作空間
8)、提交（Commit）
對各自檔案的工作副本做了更改，並將這些更改提交到倉庫
9)、衝突（Conflict）
多人對同一檔案的工作副本進行更改，並將這些更改提交到倉庫
10)、合併（Merge）
將某分支上的更改聯接到此主幹或同為主幹的另一個分支
11)、分支（Branch）
從主線上分離開的副本，預設分支叫master
12)、鎖（Lock）
獲得修改檔案的專有許可權。
13)、頭（HEAD）
頭是一個象徵性的參考，最常用以指向當前選擇的分支。
14)、修訂（Revision）
表示程式碼的一個版本狀態。Git通過用SHA1 hash演算法表示的ID來標識不同的版本。
15)、標記（Tags）
標記指的是某個分支某個特定時間點的狀態。通過標記，可以很方便的切換到標記時的狀態。
1.3、常見的版本控制器
主流的版本控制器有如下這些：
- Git
- SVN（Subversion）
- CVS（Concurrent Versions System）
- VSS（Micorosoft Visual SourceSafe）
- TFS（Team Foundation Server）
- Visual Studio Online
版本控制產品非常的多（Perforce、Rational ClearCase、RCS（GNU Revision Control System）、Serena Dimention、SVK、BitKeeper、Monotone、Bazaar、Mercurial、SourceGear Vault），現在影響力最大且使用最廣泛的是Git與SVN
1.4、版本控制分類
1.4.1、本地版本控制
記錄檔案每次的更新，可以對每個版本做一個快照，或是記錄補丁檔案，適合個人用，如RCS。
1.4.2、集中版本控制
所有的版本資料都儲存在伺服器上，協同開發者從伺服器上同步更新或上傳自己的修改
所有的版本資料都存在伺服器上，使用者的本地只有自己以前所同步的版本，如果不連網的話，使用者就看不到歷史版本，也無法切換版本驗證問題，或在不同分支工作。而且，所有資料都儲存在單一的伺服器上，有很大的風險這個伺服器會損壞，這樣就會丟失所有的資料，當然可以定期備份。代表產品：SVN、CVS、VSS
1.4.3、分散式版本控制
所有版本資訊倉庫全部同步到本地的每個使用者，這樣就可以在本地檢視所有版本歷史，可以離線在本地提交，只需在連網時push到相應的伺服器或其他使用者那裡。由於每個使用者那裡儲存的都是所有的版本資料，只要有一個使用者的裝置沒有問題就可以恢復所有的資料，但這增加了本地儲存空間的佔用。
1.5、Git與SVN最主要區別
SVN是集中式版本控制系統，版本庫是集中放在中央伺服器的，而工作的時候，用的都是自己的電腦，所以首先要從中央伺服器得到最新的版本，然後工作，完成工作後，需要把自己做完的活推送到中央伺服器。集中式版本控制系統是必須聯網才能工作，對網路頻寬要求較高。
Git是分散式版本控制系統，沒有中央伺服器，每個人的電腦就是一個完整的版本庫，工作的時候不需要聯網了，因為版本都在自己電腦上。協同的方法是這樣的：比如說自己在電腦上改了檔案A，其他人也在電腦上改了檔案A，這時，你們兩之間只需把各自的修改推送給對方，就可以互相看到對方的修改了。
二、Git安裝與配置
2.1、什麼是Git
Git是目前世界上最先進的分散式版本控制系統。
Git是免費、開源的
最初Git是為輔助 Linux 核心開發的，來替代 BitKeeper
作者：Linux和Git之父李納斯·託沃茲（Linus Benedic Torvalds）1969、芬蘭
優點：
- 適合分散式開發，強調個體。
- 公共伺服器壓力和資料量都不會太大。
- 速度快、靈活。
- 任意兩個開發者之間可以很容易的解決衝突。
- 離線工作。
缺點：
- 模式上比SVN更加複雜。
- 不符合常規思維。
- 程式碼保密性差，一旦開發者把整個庫克隆下來就可以完全公開所有程式碼和版本資訊。
原始碼： https://github.com/git/git/
2.2、搭建Git工作環境
2.2.1、下載Git
開啟 git官網，下載git對應作業系統的版本。
選擇版本：
這裡我選擇下載64-bit Git for Windows Setup
2.2.2、安裝Git
選擇安裝配置資訊
一直Next預設就好了，如果需要設定就要仔細讀一下安裝介面上的選項。
2.2.3、啟動Git
安裝成功後在開始選單中會有Git項，選單下有3個程式：
Git Bash：Unix與Linux風格的命令列，使用最多，推薦最多
與DOS風格的命令有些區別，不習慣可以選擇Git CMD
Git CMD：Windows風格的命令列
Git GUI：圖形介面的Git，不建議初學者使用，儘量先熟悉常用命令
點選Create New Repository可以直接建立一個新的倉庫。
2.2.4、Linux與Mac OS安裝Git
Linux安裝Git：sudo apt-get install git 命令列就可以安裝了。
Mac OS安裝Git： https://git-scm.com/download/mac，下載雙擊.pkg安裝
2.2.5、Bash基本操作命令
~就是home
進入Bash預設位置，注意標題欄
1）、cd : 改變目錄。
cd ~ 回Home（windows是當前使用者所在目錄）
2）、cd . . 回退到上一個目錄，直接cd進入預設目錄
3）、pwd : 顯示當前所在的目錄路徑。
4）、ls(ll): 都是列出當前目錄中的所有檔案，只不過ll(兩個ll)列出的內容更為詳細。
5）、touch : 新建一個檔案 如 touch index.js 就會在當前目錄下新建一個index.js檔案。
6）、rm: 刪除一個檔案, rm index.js 就會把index.js檔案刪除。
7）、mkdir: 新建一個目錄,就是新建一個資料夾。
8）、rm -r : 刪除一個資料夾, rm -r src 刪除src目錄， 好像不能用萬用字元。
9）、mv 移動檔案, mv index.html src index.html 是我們要移動的檔案, src 是目標資料夾,當然, 這樣寫,必須保證檔案和目標資料夾在同一目錄下。
10）、reset 重新初始化終端/清屏。
11）、clear 清屏。
12）、history 檢視命令歷史。
13）、help 幫助。
14）、exit 退出。
15）、#表示註釋
16）、輸出與註釋
17）、建立檔案
小於號：命令預設從鍵盤獲得的輸入，改成從檔案，或者其它開啟檔案以及裝置輸入
>> 是追加內容
> 是覆蓋原有內容
18、顯示檔案內容 cat
2.3、Git配置 -git config
2.3.1、檢視配置 -git config -l
使用git config -l 可以檢視現在的git環境詳細配置
檢視不同級別的配置檔案：
#檢視系統config git config --system --list #檢視當前使用者（global）配置 git config --global --list#檢視當前倉庫配置資訊
git config --local --list
2.3.2、Git配置檔案分類
在Windows系統中，Git在$HOME目錄中查詢.gitconfig檔案（一般位於C:\Documents and Settings$USER下）
Git相關的配置檔案有三個：
1）、 /etc/gitconfig：包含了適用於系統所有使用者和所有專案的值。(Win：C:\Program Files\Git\mingw64\etc\gitconfig) --system 系統級
2）、~/.gitconfig：只適用於當前登入使用者的配置。(Win：C:\Users\Administrator\.gitconfig) --global 全域性
3）、位於git專案目錄中的.git/config：適用於特定git專案的配置。(Win：C:\gitProject) --local當前專案
注意：對於同一配置項，三個配置檔案的優先順序是1<2<3
這裡可以直接編輯配置檔案，通過命令設定後會響應到這裡。
2.3.3、設定使用者名稱與郵箱（使用者標識，必要）
當你安裝Git後首先要做的事情是設定你的使用者名稱稱和e-mail地址。這是非常重要的，因為每次Git提交都會使用該資訊。它被永遠的嵌入到了你的提交中：
$ git config --global user.name "zhangguo" #名稱 $ git config --global user.email zhangguo@qq.com #郵箱
只需要做一次這個設定，如果你傳遞了--global選項，因為Git將總是會使用該資訊來處理你在系統中所做的一切操作。如果你希望在一個特定的專案中使用不同的名稱或e-mail地址，你可以在該專案中執行該命令而不要--global選項。 總之--global為全域性配置，不加為某個專案的特定配置。
2.3.4、新增或刪除配置項
1）、新增配置項git config [--local|--global|--system] section.key value [--local|--global|--system] #可選的，對應本地，全域性，系統不同級別的設定，請看2.3.2 section.key #區域下的鍵 value #對應的值
--local 專案級
--global 當前使用者級
--system 系統級
例如我們要在student區域下新增一個名稱為height值為198的配置項，執行結果如下：
2）、刪除配置項
git config [--local|--global|--system] --unset section.key
將系統級的height配置項移除
2.3.5、更多配置項
git config --global color.ui true #開啟所有的預設終端著色 git config --global alias.ci commit #別名 ci 是commit的別名 [alias] co = checkout ci = commit st = status pl = pull ps = push dt = difftool l = log --stat cp = cherry-pick ca = commit -a b = branchuser.name #使用者名稱
user.email #郵箱
core.editor #文字編輯器
merge.tool #差異分析工具
core.paper "less -N" #配置顯示方式
color.diff true #diff顏色配置
alias.co checkout #設定別名
git config user.name #獲得使用者名稱
git config core.filemode false #忽略修改許可權的檔案
所有config命令引數
語法: git config [<options>]
檔案位置
--global #use global config file 使用全域性配置檔案
--system #use system config file 使用系統配置檔案
--local #use repository config file 使用儲存庫配置檔案
-f, --file <file> #use given config file 使用給定的配置檔案
--blob <blob-id> #read config from given blob object 從給定的物件中讀取配置
動作
--get #get value: name [value-regex] 獲得值：[值]名[正則表示式]
--get-all #get all values: key [value-regex] 獲得所有值：[值]名[正則表示式]
--get-regexp #get values for regexp: name-regex [value-regex] 得到的值根據正則
--get-urlmatch #get value specific for the URL: section[.var] URL 為URL獲取特定的值
--replace-all #replace all matching variables: name value [value_regex] 替換所有匹配的變數：名稱值[ value_regex ]
--add #add a new variable: name value 新增一個新變數：name值
--unset #remove a variable: name [value-regex] 刪除一個變數名[值]：正則表示式
--unset-all #remove all matches: name [value-regex] 刪除所有匹配的正則表示式：名稱[值]
--rename-section #rename section: old-name new-name 重新命名部分：舊名稱 新名稱
--remove-section #remove a section: name 刪除部分：名稱
-l, --list #list all 列出所有
-e, --edit #open an editor 開啟一個編輯器
--get-color #find the color configured: slot [default] 找到配置的顏色：插槽[預設]
--get-colorbool #find the color setting: slot [stdout-is-tty] 發現顏色設定：槽[ stdout是TTY ]
型別
--bool #value is "true" or "false" 值是“真”或“假”。
--int #value is decimal number 值是十進位制數。
--bool-or-int #value is --bool or --int 值--布林或int
--path #value is a path (file or directory name) 值是路徑（檔案或目錄名）
其它
-z, --null #terminate values with NUL byte 終止值與null位元組
--name-only #show variable names only 只顯示變數名
--includes #respect include directives on lookup 尊重包括查詢指令
--show-origin #show origin of config (file, standard input, blob, command line) 顯示配置（檔案、標準輸入、資料塊、命令列）的來源
三、Git理論基礎
3.1、工作區域
Git本地有三個工作區域：工作目錄（Working Directory）、暫存區(Stage/Index)、資源庫(Repository或Git Directory)。如果在加上遠端的git倉庫(Remote Directory)就可以分為四個工作區域。檔案在這四個區域之間的轉換關係如下：
- Workspace：工作區，就是你平時存放專案程式碼的地方
- Index / Stage：暫存區，用於臨時存放你的改動，事實上它只是一個檔案，儲存即將提交到檔案列表資訊
- Repository：倉庫區（或本地倉庫），就是安全存放資料的位置，這裡面有你提交到所有版本的資料。其中HEAD指向最新放入倉庫的版本
- Remote：遠端倉庫，託管程式碼的伺服器，可以簡單的認為是你專案組中的一臺電腦用於遠端資料交換
本地的三個區域確切的說應該是git倉庫中HEAD指向的版本
- Directory：使用Git管理的一個目錄，也就是一個倉庫，包含我們的工作空間和Git的管理空間。
- WorkSpace：需要通過Git進行版本控制的目錄和檔案，這些目錄和檔案組成了工作空間。
- .git：存放Git管理資訊的目錄，初始化倉庫的時候自動建立。
- Index/Stage：暫存區，或者叫待提交更新區，在提交進入repo之前，我們可以把所有的更新放在暫存區。
- Local Repo：本地倉庫，一個存放在本地的版本庫；HEAD會只是當前的開發分支（branch）。
- Stash：隱藏，是一個工作狀態儲存棧，用於儲存/恢復WorkSpace中的臨時狀態。
3.2、工作流程
git的工作流程一般是這樣的：
１、在工作目錄中新增、修改檔案；
２、將需要進行版本管理的檔案放入暫存區域；
３、將暫存區域的檔案提交到git倉庫。
因此，git管理的檔案有三種狀態：已修改（modified）,已暫存（staged）,已提交(committed)
3.3、圖解教程
個人認為Git的原理相比別的版本控制器還是複雜一些的，有一份圖解教程比較直觀：
四、Git操作
4.1、建立工作目錄與常用指令
工作目錄（WorkSpace)一般就是你希望Git幫助你管理的資料夾，可以是你專案的目錄，也可以是一個空目錄，建議不要有中文。
日常使用只要記住下圖6個命令：
4.2、獲得GIT倉庫
建立本地倉庫的方法有兩種：一種是建立全新的倉庫，另一種是克隆遠端倉庫。
4.2.1、建立全新倉庫
需要用GIT管理的專案的根目錄執行：
# 在當前目錄新建一個Git程式碼庫 $ git init
執行：
結果：
執行後可以看到，僅僅在專案目錄多出了一個.git目錄，關於版本等的所有資訊都在這個目錄裡面。
當然如果使用如下命令，可以把建立目錄與倉庫一起完成：
# 新建一個目錄，將其初始化為Git程式碼庫 $ git init [project-name]
執行命令與執行結果：
4.2.2、克隆遠端倉庫
另一種方式是克隆遠端目錄，由於是將遠端伺服器上的倉庫完全映象一份至本地，而不是取某一個特定版本，所以用clone而不是checkout，語法格式如下：
# 克隆一個專案和它的整個程式碼歷史(版本資訊) $ git clone [url]
執行：
比如我們要從克隆的遠端倉庫託管在github上，地址為：https://github.com/zhangguo5/SuperPlus.git，這是一個公開的專案
結果：
4.3、GIT檔案操作
版本控制就是對檔案的版本控制，要對檔案進行修改、提交等操作，首先要知道檔案當前在什麼狀態，不然可能會提交了現在還不想提交的檔案，或者要提交的檔案沒提交上。GIT不關心檔案兩個版本之間的具體差別，而是關心檔案的整體是否有改變，若檔案被改變，在新增提交時就生成檔案新版本的快照，而判斷檔案整體是否改變的方法就是用SHA-1演算法計算檔案的校驗和。
4.3.1、檔案4種狀態
-
Untracked: 未跟蹤, 此檔案在資料夾中, 但並沒有加入到git庫, 不參與版本控制. 通過
git add狀態變為Staged. -
Unmodify: 檔案已經入庫, 未修改, 即版本庫中的檔案快照內容與資料夾中完全一致. 這種型別的檔案有兩種去處, 如果它被修改, 而變為
Modified. 如果使用git rm移出版本庫, 則成為Untracked檔案 -
Modified: 檔案已修改, 僅僅是修改, 並沒有進行其他的操作. 這個檔案也有兩個去處, 通過
git add可進入暫存staged狀態, 使用git checkout則丟棄修改過, 返回到unmodify狀態, 這個git checkout即從庫中取出檔案, 覆蓋當前修改 -
Staged: 暫存狀態. 執行
git commit則將修改同步到庫中, 這時庫中的檔案和本地檔案又變為一致, 檔案為Unmodify狀態. 執行git reset HEAD filename取消暫存, 檔案狀態為Modified
4.3.2、檢視檔案狀態
上面說檔案有4種狀態，通過如下命令可以檢視到檔案的狀態：
#檢視指定檔案狀態 git status [filename]#檢視所有檔案狀態
git status
命令：
結果：
foo.htm檔案的狀態為untracked（未跟蹤），提示通過git add可以暫存
GIT在這一點做得很好，在輸出每個檔案狀態的同時還說明了怎麼操作，像上圖就有怎麼暫存、怎麼跟蹤檔案、怎麼取消暫存的說明。
4.3.3、新增檔案與目錄
工作區（Working Directory）就是你在電腦裡能看到的目錄。
版本庫（Repository）工作區有一個隱藏目錄.git，這個不算工作區，而是Git的版本庫。
Git的版本庫裡存了很多東西，其中最重要的就是稱為stage（或者叫index）的暫存區，還有Git為我們自動建立的第一個分支master，以及指向master的一個指標叫HEAD。
將untracked狀態的檔案新增到暫存區，語法格式如下：
# 新增指定檔案到暫存區 $ git add [file1] [file2] ...# 新增指定目錄到暫存區，包括子目錄
$ git add [dir]# 添加當前目錄的所有檔案到暫存區
$ git add .
執行：
4.3.4、移除檔案與目錄（撤銷add）
當執行如下命令時，會直接從暫存區刪除檔案，工作區則不做出改變
#直接從暫存區刪除檔案，工作區則不做出改變 git rm --cached <file>
執行命令
通過重寫目錄樹移除add檔案：
#如果已經用add 命令把檔案加入stage了，就先需要從stage中撤銷 git reset HEAD <file>...
當執行 “git reset HEAD” 命令時，暫存區的目錄樹會被重寫，被 master 分支指向的目錄樹所替換，但是工作區不受影響。
示例：把f1.txt檔案從暫存區撤回工作區
移除所有未跟蹤檔案
#移除所有未跟蹤檔案 #一般會加上引數-df，-d表示包含目錄，-f表示強制清除。 git clean [options]
示例：
移除前：
執行移除：
移除後：
#只從stage中刪除，保留物理檔案 git rm --cached readme.txt#不但從stage中刪除，同時刪除物理檔案
git rm readme.txt#把a.txt改名為b.txt
git mv a.txt b.txt
當執行提交操作（git commit）時，暫存區的目錄樹寫到版本庫（物件庫）中，master 分支會做相應的更新。即 master 指向的目錄樹就是提交時暫存區的目錄樹。
當執行 “git reset HEAD” 命令時，暫存區的目錄樹會被重寫，被 master 分支指向的目錄樹所替換，但是工作區不受影響。
當執行 “git rm –cached <file>” 命令時，會直接從暫存區刪除檔案，工作區則不做出改變。
當執行 “git checkout .” 或者 “git checkout — <file>” 命令時，會用暫存區全部或指定的檔案替換工作區的檔案。這個操作很危險，會清除工作區中未新增到暫存區的改動。
當執行 “git checkout HEAD .” 或者 “git checkout HEAD <file>” 命令時，會用 HEAD 指向的 master 分支中的全部或者部分檔案替換暫存區和以及工作區中的檔案。這個命令也是極具危險性的，因為不但會清除工作區中未提交的改動，也會清除暫存區中未提交的改 動。
4.3.5、檢視檔案修改後的差異
git diff用於顯示WorkSpace中的檔案和暫存區檔案的差異
用"git status"只能檢視對哪些檔案做了改動，如果要看改動了什麼，可以用：
#檢視檔案修改後的差異 git diff [files]
命令：
---a表示修改之前的檔案，+++b表示修改後的檔案
#比較暫存區的檔案與之前已經提交過的檔案 git diff --cached
也可以把WorkSpace中的狀態和repo中的狀態進行diff，命令如下:
#比較repo與工作空間中的檔案差異 git diff HEAD~n
4.3.6、簽出
如果倉庫中已經存在檔案f4.txt，在工作區中對f4修改了，如果想撤銷可以使用checkout，簽出覆蓋
檢出命令git checkout是git最常用的命令之一，同時也是一個很危險的命令，因為這條命令會重寫工作區
語法：
#用法一 git checkout [-q] [<commit>] [--] <paths>... #用法二 git checkout [<branch>] #用法三 git checkout [-m] [[-b]--orphan] <new_branch>] [<start_point>]
<commit>是可選項，如果省略則相當於從暫存區（index）進行檢出
$ git checkout branch #檢出branch分支。要完成圖中的三個步驟，更新HEAD以指向branch分支，以及用branch 指向的樹更新暫存區和工作區。 $ git checkout #彙總顯示工作區、暫存區與HEAD的差異。 $ git checkout HEAD #同上 $ git checkout -- filename #用暫存區中filename檔案來覆蓋工作區中的filename檔案。相當於取消自上次執行git add filename以來（如果執行過）的本地修改。 $ git checkout branch -- filename #維持HEAD的指向不變。用branch所指向的提交中filename替換暫存區和工作區中相 應的檔案。注意會將暫存區和工作區中的filename檔案直接覆蓋。 $ git checkout -- . 或寫作 git checkout . #注意git checkout 命令後的引數為一個點（“.”）。這條命令最危險！會取消所有本地的 #修改（相對於暫存區）。相當於用暫存區的所有檔案直接覆蓋本地檔案，不給使用者任何確認的機會！ $ git checkout commit_id -- file_name #如果不加commit_id，那麼git checkout -- file_name 表示恢復檔案到本地版本庫中最新的狀態。
示例：
4.3.6、忽略檔案
有些時候我們不想把某些檔案納入版本控制中，比如資料庫檔案，臨時檔案，設計檔案等
在主目錄下建立".gitignore"檔案，此檔案有如下規則：
- 忽略檔案中的空行或以井號（#）開始的行將會被忽略。
- 可以使用Linux萬用字元。例如：星號（*）代表任意多個字元，問號（？）代表一個字元，方括號（[abc]）代表可選字元範圍，大括號（{string1,string2,...}）代表可選的字串等。
- 如果名稱的最前面有一個感嘆號（!），表示例外規則，將不被忽略。
- 如果名稱的最前面是一個路徑分隔符（/），表示要忽略的檔案在此目錄下，而子目錄中的檔案不忽略。
- 如果名稱的最後面是一個路徑分隔符（/），表示要忽略的是此目錄下該名稱的子目錄，而非檔案（預設檔案或目錄都忽略）。
如：
#為註釋 *.txt #忽略所有 .txt結尾的檔案 !lib.txt #但lib.txt除外 /temp #僅忽略專案根目錄下的TODO檔案,不包括其它目錄temp build/ #忽略build/目錄下的所有檔案 doc/*.txt #會忽略 doc/notes.txt 但不包括 doc/server/arch.txt
示例：
建立一個.gitignore檔案忽視所有的日誌檔案
檢視狀態：
從上圖中可以看出2個日誌檔案並沒有新增到暫存區，直接被忽視了。
針對各種語言與專案的Git忽視檔案： https://github.com/kaedei/gitignore https://github.com/github/gitignore
通用的java忽視檔案：
# Compiled class file *.class# Log file
*.log# BlueJ files
*.ctxt# Mobile Tools for Java (J2ME)
.mtj.tmp/# Package Files #
.jar
.war
.ear
.zip
.tar.gz
.rar# virtual machine crash logs, see http://www.java.com/en/download/help/error_hotspot.xml
hs_err_pid*
通用的Visual Studio開發專案忽視檔案：
## Ignore Visual Studio temporary files, build results, and ## files generated by popular Visual Studio add-ons. ## ## Get latest from https://github.com/github/gitignore/blob/master/VisualStudio.gitignoreUser-specific files
.suo
.user
.userosscache
.sln.docstates# User-specific files (MonoDevelop/Xamarin Studio)
*.userprefs# Build results
[Dd]ebug/
[Dd]ebugPublic/
[Rr]elease/
[Rr]eleases/
x64/
x86/
bld/
[Bb]in/
[Oo]bj/
[Ll]og/# Visual Studio 2015 cache/options directory
.vs/
# Uncomment if you have tasks that create the project's static files in wwwrootwwwroot/
MSTest test Results
[Tt]est[Rr]esult/
[Bb]uild[Ll]og.# NUNIT
*.VisualState.xml
TestResult.xml# Build Results of an ATL Project
[Dd]ebugPS/
[Rr]eleasePS/
dlldata.c# Benchmark Results
BenchmarkDotNet.Artifacts/# .NET Core
project.lock.json
project.fragment.lock.json
artifacts/
**/Properties/launchSettings.json_i.c
_p.c
_i.h
.ilk
.meta
.obj
.pch
.pdb
.pgc
.pgd
.rsp
.sbr
.tlb
.tli
.tlh
.tmp
.tmp_proj
.log
.vspscc
.vssscc
.builds
.pidb
.svclog
*.scc# Chutzpah Test files
_Chutzpah*# Visual C++ cache files
ipch/
.aps
.ncb
.opendb
.opensdf
.sdf
.cachefile
.VC.db
.VC.VC.opendb# Visual Studio profiler
.psess
.vsp
.vspx
.sap# TFS 2012 Local Workspace
$tf/# Guidance Automation Toolkit
*.gpState# ReSharper is a .NET coding add-in
_ReSharper*/
.[Rr]e[Ss]harper
.DotSettings.user# JustCode is a .NET coding add-in
.JustCode# TeamCity is a build add-in
_TeamCity*# DotCover is a Code Coverage Tool
*.dotCover# AxoCover is a Code Coverage Tool
.axoCover/*
!.axoCover/settings.json# Visual Studio code coverage results
.coverage
.coveragexml# NCrunch
NCrunch*
.crunch.local.xml
nCrunchTemp_*# MightyMoose
.mm.
AutoTest.Net/# Web workbench (sass)
.sass-cache/# Installshield output folder
[Ee]xpress/# DocProject is a documentation generator add-in
DocProject/buildhelp/
DocProject/Help/.HxT
DocProject/Help/.HxC
DocProject/Help/.hhc
DocProject/Help/.hhk
DocProject/Help/*.hhp
DocProject/Help/Html2
DocProject/Help/html# Click-Once directory
publish/# Publish Web Output
.[Pp]ublish.xml
.azurePubxml
# Note: Comment the next line if you want to checkin your web deploy settings,but database connection strings (with potential passwords) will be unencrypted
.pubxml
.publishproj# Microsoft Azure Web App publish settings. Comment the next line if you want to
checkin your Azure Web App publish settings, but sensitive information contained
in these scripts will be unencrypted
PublishScripts/
# NuGet Packages
*.nupkg
# The packages folder can be ignored because of Package Restore
/packages/
# except build/, which is used as an MSBuild target.
!*/packages/build/
# Uncomment if necessary however generally it will be regenerated when needed!**/packages/repositories.config
NuGet v3's project.json files produces more ignorable files
.nuget.props
.nuget.targets# Microsoft Azure Build Output
csx/
*.build.csdef# Microsoft Azure Emulator
ecf/
rcf/# Windows Store app package directories and files
AppPackages/
BundleArtifacts/
Package.StoreAssociation.xml
_pkginfo.txt
*.appx# Visual Studio cache files
files ending in .cache can be ignored
.[Cc]ache
# but keep track of directories ending in .cache
!.[Cc]ache/# Others
ClientBin/
~$*
~
.dbmdl
.dbproj.schemaview
.jfm
.pfx
.publishsettings
orleans.codegen.cs# Since there are multiple workflows, uncomment next line to ignore bower_components
(https://github.com/github/gitignore/pull/1529#issuecomment-104372622)
bower_components/
RIA/Silverlight projects
Generated_Code/
# Backup & report files from converting an old project file
to a newer Visual Studio version. Backup files are not needed,
because we have git