首先必須說明的是, 這篇文章不是闡述GIT原理性和比較深入的文章。只是對于日常開發中比較常用的需求的總結和GIT這些命令大體的原理解釋。所以掌握這個只能說能夠應付一定的開發需求。但是如果你是個追求極值和完美的人。應該再去了解下GIT具體的模型和實現細節。需要說明的是, 技術性東西，得先入門再深入理論，這很重要，入門可以讓你不斷的進行實踐，加深理解，而不是紙上談兵，看著理論無從下手。GIT的應用我們主要掌握GIT中團隊開發協助的常用命令和場景。在這之前，我們需要先介紹一些必備概念。
repository, 使用過SVN的應該都知道，這是版本庫。何為版本庫，簡單理解就是用來存儲和檢索數據的一個倉庫，只不過我們用它來存儲代碼，來實現團隊開發中的代碼共享，以此來實現協同工作。簡單的所就是用來保證，一個軟件項目中的代碼同步。
在GIT中的版本庫一般有兩個, 一個是本地版本庫，一個是服務器版本庫(共享版本庫)。這是因為GIT本身就是設計為非集中式(分布式)版本控制器，其優點就是，當你沒有網絡的時候，你不用依賴于服務器版本庫(共享版本庫)。想一下，你使用SVN的時候，可以不用聯網嗎？如果希望一個項目交由GIT來管理，那么應該再該項目所在的同級目錄中有一個.GIT文件夾，該文件夾里存放的就是本地版本庫，這時候，當你沒有網絡的時候，可以在本地進行版本管理。再有網絡連接時候, 再將本地版本庫與共享版本庫進行同步。
在GIT中，我們使用git init命令來創建初始化一個版本庫。其會自動生產.GIT文件夾和對應的文件，這時候就能用GIT進行版本管理。git init --bare 用在(共享版本庫中)，因為在共享版本庫中, 我們不需要工程文件夾(即工作空間), 因為共享版本庫，相當于一個存放代碼的服務器，不需要工作空間。
總而言之
1.git init用在我們本地工作空間中需要進行管理的項目中。2.git init --bare用在創建共享版本庫，用來于本地版本庫進行同步，實現多人開發的版本庫。所謂的工作區, 就是你項目所在的文件夾里，都可以統稱為工作區。
該區域是用來保存要提交到本地版本庫中的所有文件, 稱為stage或index。當執行git commit指令時候，會一次性將該區域類的文件提交到本地版本庫。可以理解為相當于一個緩存區，用來緩存要交給本地版本庫管理的文件。而要將文件加入暫存區域，需要使用git add指令進行添加操作。也就是說要提交到本地版本庫需要兩步操作: git add + git commit。執行完這兩條只是提交到了本地版本庫，只能自己來使用，要是在團隊開發中，要需要執行git push提交到共享版本庫.
簡而言之，這里的HEAD指針就是一個用來標識當前所在的版本。也就是我們是通過HEAD所指向的版本來確定當前所在的版本，所以當我們進行版本切換的時候，進行的就是改變HEAD指針的指向。
由GIT的模型我們知道，要交給本地倉庫管理，我們必須先將其提交到stage中。再又stage提交到本地版本庫中，我將這步操作歸納為增。以此來于數據庫中的增概念類比，方便學習。所以我們這里所謂的增加細分而來個分為向stage中增加，和向本地版本庫中增加。需要明確的是本地版本庫的增, 是依賴于stage中的。具體的例子演示。
由于我們要模擬多人開發，所以先完成以下的準備工作。
1.創建一個SWPTest文件夾，我們準備在該文件夾中創建A用戶的工作空間，和共享代碼庫。
執行如下操作
mkdir SWPTest cd SWPTest/ mkdir AWorker sharedRep2.創建共享版本庫(模擬遠程版本庫)
cd sharedRepgit init --bare3.用戶A將服務器上版本庫下載下來，準備工作。并加入.gitigonre忽略文件(用來過濾掉項目中不提交給版本庫進行管理的文件)。(記得在SWPTest根目錄位置執行命令)
cd AWordergit clone ../sharedRep/ touch .gitignore // 在工作區創建了.gitignore文件open .gitignoregit add .gitignore // 執行完這步, 將工作區的.gitignore文件提交到了暫存區(緩存區)git status -s // 查詢的是工作區與暫存區的文件狀態(文件狀態的理解是重點)git commit -m "添加gitignore文件" // 執行完之后，一次性將暫存區的內容提交到本地版本庫。此時暫存區清空。然后向.gitignore文件中粘貼object-c的忽略信息。(Github上搜索gitignore)
總結：以上三小步，分別為服務器端的版本庫的創建(1,2), 與客戶端(3,)clone到本地(如果該工程沒有gitignore文件, 最好自己加上,并添加到本地版本庫和服務端版本庫(共享版本庫))。
1.向stage中增加(提交): git add <file> // <file>值的是要交給git管理的文件，上面第三步的最后一小步，就是stage添加2.向本地版本庫種增加(提交)： git commit // 基于stage緩存3.向共享版本庫增加(提交): git push origin master // 將當前的暫存區的所有數據提交到共享版本庫(遠程版本庫)在執行完上面3個小步驟時候，你也可以立即將該文件同步到共享代碼庫，方便其它同事的使用。git push origin master // 提交到主分支在進行刪除模擬前，我們先做如下準備工作，創建a.m, b.m, c.m三個源文件。并準備將其交給本地版本庫管理。所以進行向stage添加操作。具體如下
suweipeng:sharedRep sixleaves$ touch a.m b.m c.msuweipeng:sharedRep sixleaves$ git add *.msuweipeng:sharedRep sixleaves$ git status -sA a.mA b.mA c.msuweipeng:sharedRep sixleaves$ 當查詢當前暫存區的文件狀態的時候，會發現，已經變成A(第一欄表示暫存區，第二欄表示工作區)，表示已經添加到暫存區域, 狀態為A(add)。接著我們開始研究刪除。通過模型，我們可以知道，git中又有三塊存儲文件的地方，分別是工作區、暫存區(stage)、分支。所以，我們應該在學習之前就問自己一個問題，如果有刪除操作，是針對哪塊區域的。我們通過具體操作來理解，如下(針對的緩存區和工作區一起刪除)
suweipeng:sharedRep sixleaves$ git rm a.m error: the following file has changes staged in the index: a.m (use --cached to keep the file, or -f to force removal) suweipeng:sharedRep sixleaves$ git rm -f a.m rm 'a.m' suweipeng:sharedRep sixleaves$ ls -al total 8 drwxr-xr-x 6 sixleaves staff 204 7 21 16:43 . drwxr-xr-x 3 sixleaves staff 102 7 21 11:34 .. drwxr-xr-x 13 sixleaves staff 442 7 21 16:43 .git -rw-r--r--@ 1 sixleaves staff 836 7 21 15:59 .gitignore -rw-r--r-- 1 sixleaves staff 0 7 21 16:27 b.m -rw-r--r-- 1 sixleaves staff 0 7 21 16:27 c.m suweipeng:sharedRep sixleaves$ 第一行的意思是將a.m這個文件從工作區，并在暫存區響應的文件中標記刪除操作。但是提示出錯，根據提示，我們可以使用-f來強制執行。
在Git 2.0中已經支持一種更加容易理解的方式來進行文件的刪除。
新方法:
現在我們直接使用系統自帶的rm程序來刪除，而不使用git rm。步驟如下
1.使用rm刪除工作區的文件。2.使用git add <刪除的文件名>將工作區的刪除添加到暫存區。(刪除工作區、暫存區中指定的文件)3.使用git commit -m "刪除文件b"。將文件從本地倉庫中刪除。(刪除工作區、暫存區中件、本地版本庫指定的文)4.使用git push origin master. 則這時候，不僅可以將本地版本庫中的文件刪除，同時也將共享版本庫中的文件刪除。((刪除工作區、暫存區中件、本地版本庫、共享版本庫指定的文件)。也許你會想問，那么如果是已經提交到本地版本庫中的文件呢？只是想將其從本地版本庫中刪除，是不能用這種新方法的，因為這種方法的前提你要刪除工作區間的文件，并且讓版本庫中的也刪除。那么如何應對這種需求，請看下面。
git rm剖析:此時我們來驗證git rm的作用區域，在驗證的時候，我這邊只剩下一個e.m文件，并且已經交給git管理。此時再重新創建b.m與c.m并將其交給git管理。
具體分析:首先怎么驗證所git rm -f a.m刪除的是這兩個區域的呢？如果一個文件已經提交到版本庫中，那么此時在使用該操作會不會影響版本庫呢？答案是否定的，它只影響暫存區和工作區，也就是所只刪除這兩個區域的元素。驗證思路很簡單，我們創建一個文件z.m,然后將其提交給本地版本庫進行管理，在提交的后，暫存區就清空了，所以此時只剩下版本庫和工作區又這個文件，此時我們執行git rm，接著在同步到共享版本庫，再另外一個員工的工作目錄中clone下共享版本庫，查看是否存在z.m。如果存在z.m，那么也就是所git rm是不會影響版本庫的中已經存在的文件。
在AWorker的工作空間中，此時AWork的暫存區存在兩個文件，將其提交到本地版本庫中進行管理。并同步到共享版本庫中。接著我們刪除git rm刪除其中b.m這個文件，由于此時暫存區沒有存在該文件，工作區有所以git rm不會提示錯誤。這時候假設git rm對本地版本庫有影響，則我們再本地版本庫同步到共享版本庫，如果有影響，則此時的共享版本庫就不會存在該文件。于是我們又在BWorker中進行git pull指令來驗證。
AWorker
suweipeng:sharedRep sixleaves$ git status -s A b.m A c.m suweipeng:sharedRep sixleaves$ git commit -m "添加b、c文件" [master b8e8cc9] 添加b、c文件 2 files changed, 0 insertions(+), 0 deletions(-) create mode 100644 b.m create mode 100644 c.m suweipeng:sharedRep sixleaves$ git push origin master Counting objects: 2, done. Delta comPRession using up to 4 threads. Compressing objects: 100% (2/2), done. Writing objects: 100% (2/2), 288 bytes | 0 bytes/s, done. Total 2 (delta 0), reused 0 (delta 0) To /Users/sixleaves/SWPTest/AWorker/../sharedRep/ 97b6aa0..b8e8cc9 master -> master suweipeng:sharedRep sixleaves$ git rm b.m rm 'b.m' suweipeng:sharedRep sixleaves$ ls -l total 0 -rw-r--r-- 1 sixleaves staff 0 7 21 17:27 c.m -rw-r--r-- 1 sixleaves staff 0 7 21 17:16 e.m suweipeng:sharedRep sixleaves$ git push origin master Everything up-to-date suweipeng:sharedRep sixleaves$ 在BWorker中進行git pull指令，具體細節如下，可以看到BWorker工作區間在pull之后，存在b.m c.m e.m所以我們可以得出結論git rm針對的只是工作區和暫存區域，當兩個區域同時存在該文件的時候，進行刪除操作會出錯，我們需要詳細說明是不是要保存工作區的文件。
BWorker
suweipeng:sharedRep sixleaves$ pwd /Users/sixleaves/SWPTest/BWorker/sharedRep suweipeng:sharedRep sixleaves$ git pull remote: Counting objects: 2, done. remote: Compressing objects: 100% (2/2), done. remote: Total 2 (delta 0), reused 0 (delta 0) Unpacking objects: 100% (2/2), done. From /Users/sixleaves/SWPTest/BWorker/../sharedRep 97b6aa0..b8e8cc9 master -> origin/master Updating 97b6aa0..b8e8cc9 Fast-forward b.m | 0 c.m | 0 2 files changed, 0 insertions(+), 0 deletions(-) create mode 100644 b.m create mode 100644 c.m suweipeng:sharedRep sixleaves$ ls -al total 8 drwxr-xr-x 7 sixleaves staff 238 7 21 19:00 . drwxr-xr-x 3 sixleaves staff 102 7 21 17:18 .. drwxr-xr-x 15 sixleaves staff 510 7 21 19:00 .git -rw-r--r-- 1 sixleaves staff 836 7 21 17:18 .gitignore -rw-r--r-- 1 sixleaves staff 0 7 21 19:00 b.m -rw-r--r-- 1 sixleaves staff 0 7 21 19:00 c.m -rw-r--r-- 1 sixleaves staff 0 7 21 17:18 e.m suweipeng:sharedRep sixleaves$ 最后分別針對這三個區域總結，如下
1、針對工作區域的刪除: (如果文件是已經交給git管理)這種情況，也必須同步版本庫，所以其實就是新方法的完整流程。 如果是還沒提交給git管理，此時直接是用rm刪除即可。2、針對暫存區域的刪除(而不刪除工作區): git rm <文件名> --cached 3、針對分支(版本庫)的刪除: 所謂的針對分支的刪除其實是沒必要的，因為每次提交的時候都會產生一個新版本。 如果出錯，我們可以直接使用git reset 進行版本回退。所以如果你想做到針對版本庫的刪除效果，就只能使用版本回退。其它： 4、針對同時刪除工作區域和暫存區域的: git rm -f <file>需要明確的一點是，當你把文件交給git管理的時候，一旦你一修改一個文件(無論是換行還是空格都算)，git就會追蹤到此時文件發生了變化。也就是所此時你必須再每次改完后，add到暫存區，然后進行commit?？傄氖乱。?！每次修改完都必須add到暫存區，保持暫存區該份文件的最新狀態，這樣在commit之后，版本庫中保存的才是我們修改的文件?。。 ＳX得改也就這個注意點，是比較簡單的，所以具體的操作，可以常見官方文檔。
所以我把改分為兩種，一種是針對自己編程任務進行編碼的"改"。一種是你需要從共享版本庫種更新下來最新代碼的"改"。前者不在復述，后者簡單說一下。
在git中，我們可以使用git pull來更新一個已經和共享版本庫關聯起來的本地版本庫，和相應的工作區間。嚴謹點來說git pull = git fetch + merge。即一步是取數據，一步是合并數據，所以git pull可能會在合并時候產生數據沖突，后面會詳細介紹產生沖突的解決方案。這邊暫且掌握簡單的更新操作即可。
所謂的查有兩種，一種是查看版本記錄。一種是查看暫緩區和工作區的中的文件差別，以此來判斷時候要更新暫緩區的文件。
查看版本記錄:就是進行版本的查看(git log、git reflog)。前者是當前存在的可追溯的版本，后者是歷史記錄中存在的版本。一般如果我們要回退版本的話，使用git reflog會更方便，應該它可以查看到所有的版本的歷史記錄。
suweipeng:sharedRep sixleaves$ git logcommit 7f0486eda9bfcaaae56ec8382be580d446d854d3Author: sixleaves <[email protected]>Date: Tue Jul 21 20:09:53 2015 +0800 添加了main.mcommit 97b6aa090388d0fc1b73eaeb615d86faf83807f7Author: sixleaves <[email protected]>Date: Tue Jul 21 17:20:05 2015 +0800 刪除文件bcommit ef1169ef156294cfd68ac10b568781ca9ab4a15cAuthor: sixleaves <[email protected]>Date: Tue Jul 21 17:16:46 2015 +0800 添加了e文件commit 4eb100209198d1f5c7bf914bdf9776795f7753f1Author: sixleaves <[email protected]>Date: Tue Jul 21 17:15:00 2015 +0800 添加了b文件suweipeng:sharedRep sixleaves$ git reflog7f0486e HEAD@{0}: commit: 添加了main.m97b6aa0 HEAD@{1}: reset: moving to 97b6aa0b8e8cc9 HEAD@{2}: commit: 添加b、c文件97b6aa0 HEAD@{3}: commit: 刪除文件bef1169e HEAD@{4}: commit: 添加了e文件4eb1002 HEAD@{5}: commit: 添加了b文件a18151c HEAD@{6}: commit (initial): add gitignore filesuweipeng:sharedRep sixleaves$ 查看工作區的文件狀態:
git status 指令會去暫緩區中與工作區進行比較，如果是暫緩區不存在，而工作區存在的，則會顯示兩個？，表示還沒提交給git進行管理。此時可以執行git add命令將其提交到暫緩區，此時暫緩區的文件狀態，就變成了A，表示已經加入暫緩區，此時若在提交到本地版本庫，則git就可以管理該文件了，所以此時再使用git status查詢是沒有結果的，因為此時暫緩區已經清空(在執行git commit后清空)，而工作區中的文件已經交給git管理，并且沒有發送變化。
suweipeng:sharedRep sixleaves$ git status -s?? 1.msuweipeng:sharedRep sixleaves$ git add 1.msuweipeng:sharedRep sixleaves$ git status -sA 1.msuweipeng:sharedRep sixleaves$ vim 1.msuweipeng:sharedRep sixleaves$ git status -sA 1.msuweipeng:sharedRep sixleaves$ vim 1.msuweipeng:sharedRep sixleaves$ git status -sAM 1.msuweipeng:sharedRep sixleaves$ git add 1.msuweipeng:sharedRep sixleaves$ git status -sA 1.msuweipeng:sharedRep sixleaves$ git commit -m "添加1.m"[master f6378aa] 添加1.m 1 file changed, 1 insertion(+) create mode 100644 1.msuweipeng:sharedRep sixleaves$ git status -ssuweipeng:sharedRep sixleaves$ 如果修改了main.m文件，再進行查看此時，第二欄目就變成了紅色的M，表示已經修改工作區的文件，而此時git中版本庫里的文件和該文件不同，所以我們要將其同步，必須得先進行git add，此時文件狀態由工作區的M變成了暫緩區的M，并且變成綠色，而工作區的M會消失。
此時可以使用git diff查看工作區和暫緩區中具體的變化。
suweipeng:sharedRep sixleaves$ touch 2.msuweipeng:sharedRep sixleaves$ git add 2.msuweipeng:sharedRep sixleaves$ vim 2.msuweipeng:sharedRep sixleaves$ git status -sAM 2.msuweipeng:sharedRep sixleaves$ git diffdiff --git a/2.m b/2.mindex e69de29..abe4786 100644--- a/2.m+++ b/2.m@@ -0,0 +1 @@+dddddsuweipeng:sharedRep sixleaves$ 上圖的意思是在變動后的文件種，新增加了一行ddddd
查總結
1.查詢版本記錄使用git log或者git reflog。 前者記錄的是當前版本號的迭代順序(可能會因為回退而覆蓋)。 后者記錄的是所有的歷史版本記錄。(后者包含前者)。2.使用git status -s就可知道暫存區的數據是否是最新的，是否有文件沒有添加進暫存取。3.如果暫存區數據不是最新的，可以使用git diff必將查看變化的數據。git diff中的格式說明
---: 表示變動前的文件(工作區文件)。+++: 表示變動后的文件(暫存區文件)。沒有減號或加號的行表示沒有變動的行。-號的行表示第一個文件中刪除的行，+號表示第二個文件中增加的行。@@ -1,7 +1,7 @@這句話中的減號和加號分別表示第一個文件，和第二個文件。
補充: 暫存區的D和工作區的D的區別:
1.第一欄目的，也就是暫存區顯示的是綠色的D，則表示該文件已經從工作空間刪除，刪除標志提交到了暫存區，此時若再執行git commit就會將其從版本庫種刪除。2.而紅色的D，再第二欄目，表示工作空間上的文件已經被刪除，但是刪除操作還沒有提交到暫存區。只有提交到了暫存區才有機會，將其在git種刪除。顏色的紅綠只是為了讓你能迅速的分辨出暫存區和工作區的文件狀態的修改狀態。
這是第一篇GIT簡要入門的文章，如果有疑惑的地方，可以給我留言，大家相互交流。后面的文章還會再介紹git種的沖突解決等問題。
新聞熱點
疑難解答
