Git篇

安裝之後第一步

安裝 Git 之後，你要做的第一件事情就是去配置你的名字和郵箱，因為每一次提交都需要這些資訊：

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

相關推薦