git config --global user.name "bukas"
git config --global user.email "[email protected]"

獲取git配置資訊，執行以下命令：

git config --list

建立版本庫

什麼是版本庫呢？版本庫又名倉庫，英文名repository，你可以簡單理解成一個目錄，這個目錄裡面的所有檔案都可以被Git管理起來，每個檔案的修改、刪除，Git都能跟蹤，以便任何時刻都可以追蹤歷史，或者在將來某個時刻可以“還原”。

mkdir testgit && cd testgit
git init
 

瞬間Git就把倉庫建好了，細心的讀者可以發現當前目錄下多了一個.git的目錄，預設是隱藏的，用ls -ah命令就可以看見。

把檔案新增到版本庫

touch readme.md
git add readme.md

然後用命令git commit告訴Git把檔案提交到倉庫：

git commit -m "wrote a readme file"

簡單解釋一下git commit命令，-m後面輸入的是本次提交的說明，可以輸入任意內容，當然最好是有意義的，這樣你就能從歷史記錄裡方便地找到改動記錄。

一次可以add多個不同的檔案，以空格分隔：

git add a.txt b.txt c.txt
 

倉庫狀態

git status

git status命令可以讓我們時刻掌握倉庫當前的狀態。

但如果能看看具體修改了什麼內容就更好了：

git diff readme.md

版本回退

在實際工作中，我們腦子裡怎麼可能記得一個幾千行的檔案每次都改了什麼內容，不然要版本控制系統幹什麼。版本控制系統肯定有某個命令可以告訴我們歷史記錄，在Git中，我們用git log命令檢視：

git log

git log命令顯示從最近到最遠的提交日誌。如果嫌輸出資訊太多，看得眼花繚亂的，可以試試加上--pretty=oneline引數：

git log --pretty=oneline
 

需要友情提示的是，你看到的一大串類似2e70fd...376315的是commit id（版本號）

在 Git中，用HEAD表示當前版本，也就是最新的提交commit id，上一個版本就是HEAD^，上上一個版本就是HEAD^^，當然往上100個版本寫100個^比較容易數不過來，所以寫成HEAD~100。

現在我們要把當前版本回退到上一個版本，就可以使用git reset命令：

git reset --hard HEAD^

然我們用git log再看看現在版本庫的狀態，最新的那個版本已經看不到了！好比你從21世紀坐時光穿梭機來到了19世紀，想再回去已經回不去了，腫麼辦？

辦法其實還是有的，只要上面的命令列視窗還沒有被關掉，你就可以順著往上找啊找啊，假設找到那個commit id是2e70fdf...，於是就可以指定回到未來的某個版本：

git reset --hard 2e70fdf

版本號沒必要寫全，前幾位就可以了，Git會自動去找。當然也不能只寫前一兩位，因為Git可能會找到多個版本號，就無法確定是哪一個了。

現在，你回退到了某個版本，關掉了電腦，第二天早上就後悔了，想恢復到新版本怎麼辦？找不到新版本的commit id怎麼辦？

Git提供了一個命令git reflog用來記錄你的每一次命令：

git reflog

終於舒了口氣，於是你看到的commit id是2e70fdf，現在，你又可以乘坐時光機回到未來了。

工作區和暫存區

Git和其他版本控制系統如SVN的一個不同之處就是有暫存區的概念。

工作區就是你在電腦裡能看到的目錄，比如我的testgit資料夾就是一個工作區。

工作區有一個隱藏目錄.git，這個不算工作區，而是Git的版本庫。

Git的版本庫裡存了很多東西，其中最重要的就是稱為stage（或者叫index）的暫存區，還有Git為我們自動建立的第一個分支master，以及指向 master的一個指標叫HEAD。

前面講了我們把檔案往 Git 版本庫裡新增的時候，是分兩步執行的：

第一步是用git add把檔案新增進去，實際上就是把檔案修改新增到暫存區；

第二步是用git commit提交更改，實際上就是把暫存區的所有內容提交到當前分支。

因為我們建立Git版本庫時，Git自動為我們建立了唯一一個master分支，所以現在git commit就是往master分支上提交更改。

你可以簡單理解為，git add命令實際上就是把要提交的所有修改放到暫存區（Stage），然後執行git commit就可以一次性把暫存區的所有修改提交到分支。

一旦提交後，如果你又沒有對工作區做任何修改，那麼工作區就是“乾淨”的。

修改與撤銷

用git diff HEAD -- readme.md命令可以檢視工作區和版本庫裡面最新版本的區別。

git checkout -- file可以丟棄工作區的修改：

git checkout -- readme.md

命令git checkout -- readme.md意思就是，把readme.md檔案在工作區的修改全部撤銷，即讓這個檔案回到最近一次git commit或git add時的狀態。

當然也可以用git reset命令。

刪除檔案

一般情況下，你通常直接在檔案管理器中把沒用的檔案刪了，或者用rm命令刪了：

rm readme.md

這個時候，Git 知道你刪除了檔案，因此，工作區和版本庫就不一致了，git status命令會立刻告訴你哪些檔案被刪除了。

現在你有兩個選擇，一是確實要從版本庫中刪除該檔案，那就用命令git rm刪掉，並且git commit：

git rm readme.md
git commit -m "remove readme.md"

現在，檔案就從版本庫中被刪除了。

另一種情況是刪錯了，因為版本庫裡還有呢，所以可以很輕鬆地把誤刪的檔案恢復到最新版本：

git checkout -- readme.md

生成SSH key

建立 SSH Key。在使用者主目錄下，看看有沒有.ssh目錄，如果有，再看看這個目錄下有沒有id_rsa和id_rsa.pub這兩個檔案，如果已經有了，可直接跳到下一步。如果沒有，開啟 Shell（Windows下開啟Git Bash），建立SSH Key：

ssh-keygen -t rsa -C "[email protected]"

你需要把郵件地址換成你自己的郵件地址，然後一路回車，使用預設值即可。

如果一切順利的話，可以在使用者主目錄裡找到.ssh目錄，裡面有id_rsa和id_rsa.pub兩個檔案，這兩個就是SSH Key的祕鑰對，id_rsa是私鑰，不能洩露出去，id_rsa.pub是公鑰，可以放心地告訴任何人。

然後登入GitHub（或者其它Git程式碼託管平臺），開啟Account settings，SSH Keys頁面，點Add SSH Key，填上任意Title，在Key文字框裡貼上id_rsa.pub檔案的內容。

為什麼GitHub需要SSH Key呢？因為GitHub需要識別出你推送的提交確實是你推送的，而不是別人冒充的，而Git支援SSH協議，所以GitHub只要知道了你的公鑰，就可以確認只有你自己才能推送。

當然，GitHub允許你新增多個Key。假定你有若干電腦，你一會兒在公司提交，一會兒在家裡提交，只要把每臺電腦的Key都新增到GitHub，就可以在每臺電腦上往GitHub推送了。

遠端伺服器

Git 最強大的功能之一是可以有一個以上的遠端伺服器（另一個事實，你總是可以執行一個本地倉庫）。你不一定總是需要寫訪問許可權，你可以從多個伺服器中讀取（用於合併），然後寫到另一個伺服器中。新增一個遠端伺服器很簡單：

git remote add origin(別名，根據愛好命名) [email protected]:bukas/bukas.git

如果你想檢視遠端伺服器的相關資訊，你可以這樣做：

# shows URLs of each remote server
git remote -v

# gives more details about origin
git remote show origin(別名)

下一步，就可以把本地庫的所有內容推送到遠端庫上：

git push -u origin master

把本地庫的內容推送到遠端，用git push命令，實際上是把當前分支master推送到遠端。

由於遠端庫是空的，我們第一次推送master分支時，加上了-u引數，Git不但會把本地的master分支內容推送的遠端新的master分支，還會把本地的master分支和遠端的master分支關聯起來，在以後的推送或者拉取時就可以簡化命令。

從現在起，只要本地作了提交，就可以通過命令把本地master分支的最新修改推送至GitHub：

git push origin master

SSH警告

當你第一次使用Git的clone或者push命令連線GitHub時，會得到一個警告：

The authenticity of host ‘github.com (xx.xx.xx.xx)’ can’t be established.

RSA key fingerprint is xx.xx.xx.xx.xx.

Are you sure you want to continue connecting (yes/no)?

這是因為Git使用SSH連線，而SSH連線在第一次驗證GitHub伺服器的Key時，需要你確認 GitHub的Key的指紋資訊是否真的來自GitHub的伺服器，輸入yes回車即可。

從遠端庫克隆

當已經有一個遠端庫的時候，我們可以用命令git clone克隆一個本地庫：

git clone [email protected]:test/testgit.git

你也許還注意到，GitHub給出的地址不止一個，還可以用https://github.com/test/testgit.git這樣的地址。實際上Git支援多種協議，預設的git://使用ssh，但也可以使用 https等其他協議。使用https除了速度慢以外，還有個最大的麻煩是每次推送都必須輸入口令，但是在某些只開放http埠的公司內部就無法使用ssh協議而只能用https。

建立與合併分支

首先我們建立dev分支，然後切換到dev分支：

git checkout -b dev

git checkout命令加上-b引數表示建立並切換，相當於以下兩條命令：

git branch dev
git checkout dev

然後用git branch命令檢視當前分支：

git branch

我們在dev分支上進行新增修改操作，然後我們把dev分支的工作成果合併到master分支上：

git checkout master
git merge dev

git merge命令用於合併指定分支到當前分支。

注意到git merge的資訊裡面可能有Fast-forward字樣，Git告訴我們，這次合併是“快進模式”，也就是直接把master指向dev的當前提交，所以合併速度非常快。

當然也不是每次合併都能Fast-forward。

合併完成後，就可以放心地刪除dev分支了：

git branch -d dev

如果要丟棄一個沒有被合併過的分支，可以通過git branch -D <branch>強行刪除。

在本地建立和遠端分支對應的分支，使用git checkout -b branch-name origin/branch-name，本地和遠端分支的名稱最好一致；

建立本地分支和遠端分支的關聯，使用git branch --set-upstream branch-name origin/branch-name；

從遠端抓取分支，使用git pull，如果有衝突，要先處理衝突。

解決衝突

人生不如意之事十之八九，合併分支往往也不是一帆風順的。

有時候我們進行合併的時候，會提示有衝突出現CONFLICT (content)，必須手動解決衝突後再提交。git status也可以告訴我們衝突的檔案。

開啟衝突檔案我們會看到Git用<<<<<<<，=======，>>>>>>>標記出不同分支的內容，我們修改後提交：

git add readme.md
git commit -m "conflict fixed"

用帶引數的git log也可以看到分支的合併情況：

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

分支管理策略

通常，合併分支時，如果可能，Git會用Fast forward模式，但這種模式下，刪除分支後，會丟掉分支資訊。

如果要強制禁用Fast forward模式，Git就會在merge時生成一個新的commit，這樣，從分支歷史上就可以看出分支資訊。

下面我們實戰一下--no-ff方式的git merge：

首先，仍然建立並切換dev分支：

git checkout -b dev

修改readme.md檔案，並提交一個新的commit：

git add readme.md
git commit -m "add merge"

現在，我們切換回master：

git checkout master

準備合併dev分支，請注意--no-ff引數，表示禁用Fast forward：

git merge --no-ff -m "merge with no-ff" dev

Bug分支

軟體開發中，bug就像家常便飯一樣。有了bug就需要修復，在Git中，由於分支是如此的強大，所以，每個bug都可以通過一個新的臨時分支來修復，修復後，合併分支，然後將臨時分支刪除。

當你接到一個修復一個代號101的bug的任務時，很自然地，你想建立一個分支issue-101來修復它，但是，等等，當前正在dev上進行的工作還沒有提交。

並不是你不想提交，而是工作只進行到一半，還沒法提交，預計完成還需1天時間。但是，必須在兩個小時內修復該bug，怎麼辦？

幸好，Git還提供了一個stash功能，可以把當前工作現場“儲藏”起來，等以後恢復現場後繼續工作：

git stash

現在，用git status檢視工作區，就是乾淨的（除非有沒有被 Git 管理的檔案），因此可以放心地建立分支來修復bug。

首先確定要在哪個分支上修復bug，假定需要在master分支上修復，就從master建立臨時分支：

git checkout master
git checkout -b issue-101

現在修復bug，然後提交：

git add readme.md
git commit -m "fix bug 101"

修復完成後，切換到master分支，並完成合並，最後刪除issue-101分支：

git checkout master
git merge --no-ff -m "merged bug fix 101" issue-101

太棒了，原計劃兩個小時的bug修復只花了5分鐘！現在，是時候接著回到dev分支幹活了！

git checkout dev
git status

工作區是乾淨的，剛才的工作現場存到哪去了？用git stash list命令看看：

git stash list

工作現場還在，Git把stash內容存在某個地方了，但是需要恢復一下，有兩個辦法：

一是用git stash apply恢復，但是恢復後，stash內容並不刪除，你需要用git stash drop來刪除；

另一種方式是用git stash pop，恢復的同時把stash內容也刪了：

git stash pop

再用git stash list檢視，就看不到任何stash內容了。

你可以多次stash，恢復的時候，先用git stash list檢視，然後恢復指定的stash，用命令

git stash apply [email protected]{0}

標籤管理

釋出一個版本時，我們通常先在版本庫中打一個標籤，這樣，就唯一確定了打標籤時刻的版本。將來無論什麼時候，取某個標籤的版本，就是把那個打標籤的時刻的歷史版本取出來。所以，標籤也是版本庫的一個快照。

命令git tag <tagname>用於新建一個標籤，預設為HEAD，也可以指定一個commit id。

git tag -a <tagname> -m "blablabla..."可以