Git的一些基本操作
1.設定使用者資訊
設定使用者名稱和郵箱，這樣，在每次操作的時候知道是哪個使用者做的操作。
[root@CentOS1 ~]# git config --global user.name "lizexiong" [root@CentOS1 ~]# git config --global user.email "[email protected]"
查詢設定的基本資訊
[root@CentOS1 ~]# git config --list user.name=lizexiong user.email[email protected]
2.設定Git顏色
在Git查詢的時候，Git預設是沒有顏色顯示的，現在開啟顏色顯示。
[root@CentOS1 ~]# git config --global color.ui true [root@CentOS1 ~]# git config --list user.name=lizexiong user.email=[email protected] color.ui=true
3.建立版本庫
什麼是版本庫呢？版本庫又名倉庫，英文名repository，你可以簡單理解成一個目錄，這個目錄裡面的所有檔案都可以被Git管理起來，每個檔案的修改、刪除，Git都能跟蹤，以便任何時刻都可以追蹤歷史，或者在將來某個時刻可以“還原”。
建立版本庫目錄
通過git init命令把這個目錄變成Git可以管理的倉庫
瞬間Git就把倉庫建好了，而且告訴你是一個空的倉庫（empty Git repository），細心的讀者可以發現當前目錄下多了一個.git的目錄，這個目錄是Git來跟蹤管理版本庫的，沒事千萬不要手動修改這個目錄裡面的檔案，不然改亂了，就把Git倉庫給破壞了。
4.把檔案新增到版本庫
首先這裡再明確一下，所有的版本控制系統，其實只能跟蹤文字檔案的改動，比如TXT檔案，網頁，所有的程式程式碼等等，Git也不例外。版本控制系統可以告訴你每次的改動，比如在第5行加了一個單詞“Linux”，在第8行刪了一個單詞“Windows”。而圖片、視訊這些二進位制檔案，雖然也能由版本控制系統管理，但沒法跟蹤檔案的變化，只能把二進位制檔案每次改動串起來，也就是隻知道圖片從100KB改成了120KB，但到底改了啥，版本控制系統不知道，也沒法知道。
不幸的是，Microsoft的Word格式是二進位制格式，因此，版本控制系統是沒法跟蹤Word檔案的改動的，前面我們舉的例子只是為了演示，如果要真正使用版本控制系統，就要以純文字方式編寫檔案。
因為文字是有編碼的，比如中文有常用的GBK編碼，日文有Shift_JIS編碼，如果沒有歷史遺留問題，強烈建議使用標準的UTF-8編碼，所有語言使用同一種編碼，既沒有衝突，又被所有平臺所支援。
使用Windows的童鞋要特別注意：
千萬不要使用Windows自帶的記事本編輯任何文字檔案。原因是Microsoft開發記事本的團隊使用了一個非常弱智的行為來儲存UTF-8編碼的檔案，他們自作聰明地在每個檔案開頭添加了0xefbbbf（十六進位制）的字元，你會遇到很多不可思議的問題，比如，網頁第一行可能會顯示一個“?”，明明正確的程式一編譯就報語法錯誤，等等，都是由記事本的弱智行為帶來的。建議你下載Notepad++代替記事本，不但功能強大，而且免費！記得把Notepad++的預設編碼設定為UTF-8 without BOM即可：
現在我們編寫一個readme.txt檔案，內容如下：
一定要放到git目錄下（子目錄也行），因為這是一個Git倉庫，放到其他地方Git再厲害也找不到這個檔案。
第一步，用命令git add告訴Git，把檔案新增到倉庫：
沒有任何顯示就是執行成功。
[root@CentOS1 git]# git add readme.txt
第二步，這裡可以使用git status 來檢視新增的檔案:
第三步，用命令git commit告訴Git，把檔案提交到倉庫：
現在在使用git status檢視，檔案已經被提交到倉庫了
命令詳解：
簡單解釋一下git commit命令，-m後面輸入的是本次提交的說明，可以輸入任意內容，當然最好是有意義的，這樣你就能從歷史記錄裡方便地找到改動記錄。
嫌麻煩不想輸入-m "xxx"行不行？確實有辦法可以這麼幹，但是強烈不建議你這麼幹，因為輸入說明對自己對別人閱讀都很重要。實在不想輸入說明的童鞋請自行Google，我不告訴你這個引數。
git commit命令執行成功後會告訴你，1個檔案被改動（我們新新增的readme.txt檔案），插入了兩行內容（readme.txt有兩行內容）。
為什麼Git新增檔案需要add，commit一共兩步呢？因為commit可以一次提交很多檔案，所以你可以多次add不同的檔案，比如：
$ git add file1.txt $ git add file2.txt file3.txt $ git commit -m "add 3 files."
本章小結:
新增檔案到Git倉庫，分兩步：
第一步，使用命令git add <file>，注意，可反覆多次使用，新增多個檔案；
第二步，使用命令git commit，完成。
5.檔案修改之對比及檢視
上一步已經成功地新增並提交了一個readme.txt檔案，現在，是時候繼續工作了，於是，我們繼續修改readme.txt檔案，改成如下內容：
現在，執行git status命令看看結果：
git status命令可以讓我們時刻掌握倉庫當前的狀態，上面的命令告訴我們，readme.txt被修改過了，但還沒有準備提交的修改。
雖然Git告訴我們readme.txt被修改了，可以用git diff來檢視檔案哪裡修改了。
現在重新提交到倉庫，先新增要提交的檔案，檢視以下狀態。
現在git commit提交檢視狀態
當然，還可以檢視檔案變化的log。
6.版本回退
這裡為了演示，所以在修改一次檔案來對比。
像上述步驟一樣,不斷對檔案進行修改，不斷提交到版本庫裡面，就相當於玩遊戲的存檔。經過上述的提交，現在整個檔案已經經過了3次提交，2次修改。
當然，個人不可能記住自己修改了多少次，所以git log已經全部記錄了，這就是-m備註的好處。
git log命令顯示從最近到最遠的提交日誌，我們可以看到3次提交。
如果嫌輸出資訊太多，看得眼花繚亂的，可以試試加上--pretty=oneline引數：
這裡可以看到，看到的一大串類似719a775……104fe0的是commit id（版本號），和SVN不一樣，Git的commit id不是1，2，3……遞增的數字，而是一個SHA1計算出來的一個非常大的數字，用十六進位制表示，而且你看到的commit id和我的肯定不一樣，以你自己的為準。為什麼commit id需要用這麼一大串數字表示呢？因為Git是分散式的版本控制系統，後面我們還要研究多人在同一個版本庫裡工作，如果大家都用1，2，3……作為版本號，那肯定就衝突了。
現在可以看到檔案的一些資訊，開始版本回退。
- 回退方式一
首先，Git必須知道當前版本是哪個版本，在Git中，用HEAD表示當前版本，也就是最新的提交719a775……104fe0（注意我的提交ID和你的肯定不一樣），上一個版本就是HEAD^，上上一個版本就是HEAD^^，當然往上100個版本寫100個^比較容易數不過來，所以寫成HEAD~100。
- 回退方式二
回退方式一講解了直接使用HEAD回退，回退之後檢視git log，已經沒有第三版本的log記錄了。
而且用回退方式一，如果有很多版本，人為不好記錄，而且，當版本回退到之前的版本後，沒有版本log記錄了，所以這裡使用第二種方式來回退，也就是版本號的方式來回退。
檢視檔案的版本號。
本章小結
HEAD指向的版本就是當前版本，因此，Git允許我們在版本的歷史之間穿梭，使用命令git reset --hard commit_id。
穿梭前，用git log可以檢視提交歷史，以便確定要回退到哪個版本。
要重返未來，用git reflog檢視命令歷史，以便確定要回到未來的哪個版本。
7.工作區和暫存區
Git和其他版本控制系統如SVN的一個不同之處就是有暫存區的概念。
工作區（Working Directory）
就是你在電腦裡能看到的目錄，比如我的git資料夾就是一個工作區：
版本庫（Repository）
工作區有一個隱藏目錄.git，這個不算工作區，而是Git的版本庫。
Git的版本庫裡存了很多東西，其中最重要的就是稱為stage（或者叫index）的暫存區，還有Git為我們自動建立的第一個分支master，以及指向master的一個指標叫HEAD。
前面講了我們把檔案往Git版本庫裡新增的時候，是分兩步執行的：
第一步是用git add把檔案新增進去，實際上就是把檔案修改新增到暫存區；
第二步是用git commit提交更改，實際上就是把暫存區的所有內容提交到當前分支。
因為我們建立Git版本庫時，Git自動為我們建立了唯一一個master分支，所以，現在，git commit就是往master分支上提交更改。
你可以簡單理解為，需要提交的檔案修改通通放到暫存區，然後，一次性提交暫存區的所有修改。
俗話說，實踐出真知。現在，我們再練習一遍，先對readme.txt做個修改，比如加上一行內容：
然後，在工作區新增一個LICENSE文字檔案（內容隨便寫）。
先用git status檢視一下狀態：
Git非常清楚地告訴我們，readme.txt被修改了，而LICENSE還從來沒有被新增過，所以它的狀態是Untracked。
現在，使用兩次命令git add，把readme.txt和LICENSE都新增後，用git status再檢視一下：
現在，暫存區的狀態就變成這樣了：
所以，git add命令實際上就是把要提交的所有修改放到暫存區（Stage），然後，執行git commit就可以一次性把暫存區的所有修改提交到分支。
一旦提交後，如果你又沒有對工作區做任何修改，那麼工作區就是“乾淨”的：
現在版本庫變成了這樣，暫存區就沒有任何內容了
8.管理修改
本次管理修改演示的是以下步驟:
第一次修改 -> git add -> 第二次修改 -> git commit
現在檢視git status，發現，第二次修改沒有提交。
前面講了，Git管理的是修改，當你用git add命令後，在工作區的第一次修改被放入暫存區，準備提交，但是，在工作區的第二次修改並沒有放入暫存區，所以，git commit只負責把暫存區的修改提交了，也就是第一次的修改被提交了，第二次的修改不會被提交。
提交後，用git diff HEAD -- readme.txt命令可以檢視工作區和版本庫裡面最新版本的區別：
如果第二次修改想要提交，只能再次把檔案放入暫存區。然後在提交
9.撤銷修改
自然，自己也有突然覺得寫錯的時候，比如，在檔案最後新增了一行。
這裡因為還沒有新增以及提交，手動刪除這個錯誤即可，但是，如果用git status來檢視一下。Git會告訴你，git checkout -- file可以丟棄工作區的修改：
命令git checkout -- readme.txt意思就是，把readme.txt檔案在工作區的修改全部撤銷，這裡有兩種情況：
一種是readme.txt自修改後還沒有被放到暫存區，現在，撤銷修改就回到和版本庫一模一樣的狀態；
一種是readme.txt已經新增到暫存區後，又作了修改，現在，撤銷修改就回到新增到暫存區後的狀態。
總之，就是讓這個檔案回到最近一次git commit或git add時的狀態。
git checkout -- file命令中的--很重要，沒有--，就變成了“切換到另一個分支”的命令。
當然，這裡還有第二種可能，不但寫錯了一些檔案，還提交到暫存區了,慶幸的是,在commit之前，發現了這個錯誤，用git status檢視以下，修改只是提交到了暫存區，還沒有提交。
Git同樣告訴我們，用命令git reset HEAD file可以把暫存區的修改撤銷掉（unstage），重新放回工作區：
git reset命令既可以回退版本，也可以把暫存區的修改回退到工作區。當我們用HEAD時，表示最新的版本。
再用git status檢視一下，現在暫存區是乾淨的，工作區有修改：
然後在次丟棄工作區的修改
本章小結:
場景1：當你改亂了工作區某個檔案的內容，想直接丟棄工作區的修改時，用命令git checkout -- file。
場景2：當你不但改亂了工作區某個檔案的內容，還新增到了暫存區時，想丟棄修改，分兩步，第一步用命令git reset HEAD file，就回到了場景1，第二步按場景1操作。
場景3：已經提交了不合適的修改到版本庫時，想要撤銷本次提交，參考版本回退一節，不過前提是沒有推送到遠端庫。
10.刪除檔案
在Git中，刪除也是一個修改操作，我們實戰一下，先新增一個新檔案test.txt到Git並且提交：
一般情況下，通常直接在檔案管理器中把沒用的檔案刪了，或者用rm命令刪了：
這個時候，Git知道你刪除了檔案，因此，工作區和版本庫就不一致了，git status命令會立刻告訴你哪些檔案被刪除了：
現在有兩種情況選擇.
- 一是確實要從版本庫中刪除該檔案，那就用命令git rm刪掉，並且git commit；
現在，檔案就從版本庫中被刪除了。
- 另一種情況是刪錯了，因為版本庫裡還有呢，所以可以很輕鬆地把誤刪的檔案恢復到最新版本；
git checkout其實是用版本庫裡的版本替換工作區的版本，無論工作區是修改還是刪除，都可以“一鍵還原”。
本章小結：
命令git rm用於刪除一個檔案。如果一個檔案已經被提交到版本庫，那麼你永遠不用擔心誤刪，但是要小心，你只能恢復檔案到最新版本，你會丟失最近一次提交後你修改的內容。
作者：小家電維修
相見有時，後會無期。