Git是一個開源的分佈式版本控制系統，可以有效、高速的處理從很小到非常大的項目版本管理。Git是Linus Torvalds爲了幫助管理Linux內核開發而開發的一個開放源碼的版本控制軟件。本篇文章將從原始的Git命令出發，學習實際開發過程中最常用、最有效的、最基本的命令，幫助Git初學者快速融入團體開發。由於對Git的基本命令的學習是打基礎，而實際的開發過程中大多都是結合開發軟件來完成版本控制，所以學習完基本的命令行操作之後，後期推出基於IntelliJ IDEA的Git操作學習筆記。
本篇文章將主要介紹以下幾點內容：
Git的基本介紹
Git的基本操作
Git的分支操作
Git的更改提交操作
推送至遠程倉庫
從遠程倉庫獲取
一、Git的基本介紹
如何理解Git？Git是什麼？
對於剛剛加入職場的新人來說，被分配到的第一個任務往往都是：從遠程倉庫把代碼拉下來，並熟悉代碼吧。如果你以前從來沒有接觸過Git，那麼拉取代碼都會有相當大的困難，因爲你並不理解怎麼拉代碼。如果你以前接觸過Git，並在學校使用過Git來進行代碼的版本控制的話，那麼你應該對Git有個基本的認識，至少會拉取代碼，添加索引，推送代碼到遠程倉庫等基本操作。其實大家在學習過程中都有一些基本的版本控制思想，那就是在寫論文的時候，常常會保存多份文檔，分別手動在文件的命名上進行版本控制，如下圖所示：
從上圖中可以看出，使用這種原始的手動版本控制，可以做到根據時間點來控制文檔的版本，甚至可以回退到某個時間點來編寫文檔，或者是將不同時間點的文檔進行合併，但是這種人工方式的版本控制始終具有侷限性，整個版本的控制只能由一人來完成，如果多人進行控制，那必定會造成混亂，導致文檔內容雜亂不堪，使文檔的編輯人員一頭霧水。看着這一堆亂七八糟的文檔，想保留其中最新的一個版本，刪除其他的版本，但是又害怕某天被刪除的文檔會重新被利用，還不敢刪除。
以上的困擾將被Git終結，Git管理的文檔（文本文檔）允許多人對同一個文檔進行修改，各自修改的內容很方便地進行合併，並且可以基於當前內容創建新的分支，在新的分支繼續進行修改，最後合併到當前分支上，始終保證文檔是最新的。
那麼，到底什麼是Git？舉個傳統方式團隊協作的例子，Jack在開發項目時，發現某一部分需要John完成，於是他把文件複製了一份發給John，之後繼續自己的工作。第二天John將文件傳回來，可這時Jack並不知道John對文件做了哪些修改，也無法清楚地分辨出自己做過的變動，除非他們之間事先做過良好清晰的約定或者Jack等待John完成後再繼續自己的工作。
使用Git則會極大地簡化這一過程。Jack將自己的工作內容上傳到遠程倉庫中，John複製遠程倉庫內容到本地，之後兩個人各自進行自己工作。當John完成工作時，通知Jack拉取項目更新，在拉取過程中， Git會自動合併雙方的修改爲一體，如果項目成員的修改發生衝突（比如修改同一處），Git允許你手動選擇使用什麼內容來填充衝突處。這一功能也得益於Git的版本控制機制。在文件內容發生修改時，Git會將發生修改的部分劃分爲區塊進行記錄，以區塊爲單位從而實現自動合併。Git還記錄了每次修改的內容節點，在每次提交時，Git生成一個HASH值作爲版本號，我們可以通過查看項目歷史找到想要的版本，並通過版本號將當前版本回滾到指定版本。下圖是本地倉庫和中央倉庫的示意圖：
總之，Git的帶來的便捷性遠遠不止這些，在後期的使用中，你將體會到她的迷人之處。
理解Git的工作區和緩存區
工作區（
working directory）
在新建的文件夾內初始化一個Git倉庫之後，那麼當前文件夾就可以成爲是工作區，工作區內的文件是可以看見的，當然這個工作區不包括初始倉庫生成的.git文件夾。版本庫（
repository）
工作區中有一個隱藏文件夾.git，這個不算工作區，而是Git的版本庫。
Git的版本庫裏存在很多東西，其中最爲重要的是stage（或者叫index）的暫存區。還有Git爲我們自動創建的第一個分支master，以及指向master的第一個指針叫HEAD。
Git中添加，是分兩步執行的：
第一步是用git add把文件添加進去，實際上是把文件修改添加到暫存區；
第二步是git commit提交更改，實際上就是把暫存區的所有內容提交到當前分支。
可以理解爲需要提交的文件統統放在暫存區，然後，一次性提交暫存區的所有修改。
二、Git的基本操作
閱讀上面的內容之後，對Git有了一個基本的瞭解，但是要更加深刻地瞭解Git，得通過操作命令來慢慢了解。下面將介紹Git的常見命令，跟着命令來一步一步學習Git。
git init——初始化倉庫
建立一個空文件夾，如果需要使用Git對文件夾內的文本文檔進行版本管理，那麼就必須進行倉庫初始化。進入新建的文件夾中，打開命令行工具，使用git init命令。
出現上面的結果表示當前的倉庫初始化成功。初始化成功之後，會在當前文件夾生成一個.git的隱藏文件夾，這個.git文件夾裏存儲着管理當前目錄內容所需的倉庫數據。對於文件夾內的文件結構，後期將出相應的文章進行介紹。
在Git中，我們將這個目錄的內容稱爲“附屬於該倉庫的工作樹”。“工作樹”就是工作區，文件的編輯操作都在工作樹中進行，然後記錄到倉庫中，以此管理文件的歷史快照。如果想要將文件恢復到原先的狀態，可以從倉庫中調取以前的歷史快照，在工作樹中打開。具的操作方式將在後面詳細介紹。
git status——查看倉庫的狀態
git status是一個非常有用的命令，可以通過這個命令來查看倉庫的當前狀態。
因爲是剛剛初始化的倉庫，所以顯示正在處於master分支（主分支）下，關於分支內容，後面也會講到，這裏不必過於深究。接下來又顯示了沒有可以提交的內容，如果新建文件或者拷貝文件到當前工作樹，可以使用git add來進行追蹤（添加索引）。
現在我們在當前工作樹中添加一個新文件README.md作爲被管理對象，當然任何文本文件都是可以被管理的，然後再嘗試使用git status來觀察倉庫的狀態。
添加完新文件以後，倉庫的狀態變了，顯示的是當前有未被追蹤的文件README.md（這裏有一個小細節，新添加的README.md還未被Git管理的時候，顯示的是紅色，後面使用到IntelliJ IDEA的時候，新創建的*.java未被管理之前，文件顯示也將是紅色，根據顏色也可以判斷當前文件的狀態）。類似地，只要對Git的工作樹或者倉庫進行操作，git status命令的顯示結果都會發生變化。
git add——向暫存區中添加文件
如果我明只是在工作樹中添加或者修改了文件，那麼這個文件將不會被git管理，換句話說就是無法進行版本管理，那麼添加、修改完文件，需要將其用Git管理起來，那麼就需要使用到git add命令。git add後面的參數可以是一個文件夾，可以是一個文件，或者是某一類文件（*.java）等。
添加完之後，再次查看倉庫狀態，又發生了變化，顯示的是Changes to be committed，表示又未提交的修改（這裏有一個小細節，未提交修改的文件顯示的是綠色，後期在IntelliJ IDEA中顯示綠色的文件*.java表示修改後添加了索引但還未提交）。這裏還顯示了可以使用命令git rm --cached <file>來撤銷已添加到暫存區的文件，這裏只會移除添加到暫存區的數據，不會影響到工作樹中的文件，我們來具體操作一下。
這時候的狀態和添加README.md到暫存區之前的狀態一模一樣。
git commit——保存倉庫的歷史記錄
- 記錄一行提交信息
git commit命令是提交命令，是將已經添加到暫存區的文件提到到本地倉庫的歷史記錄中，通過這些記錄，就可以在日後的某一天將此時的文件狀態進行恢復。具體的命令是git commit -m "提交信息，可以是任何內容"。參數-m之後是提交的信息，一般都是記錄當前修改的內容等。
這就將README.md文件提交到了本地倉庫中，提交產生的日誌表示新增了一個文件，沒有刪除任何文件。
- 記錄詳細提交信息
有時候我們提交代碼的時候僅僅一行提交信息難以描述清楚本次修改的具體內容，所以需要寫多行描述信息，那麼我們可以直接使用git commit命令來完成多行提交信息的記錄。在此之前，我們在剛纔測試的文件中添加一些內容，然後重新提交，測試多行描述信息編寫的功能，最後測試git commit命令。
對其添加了一些內容之後，必須添加索引後纔可以進行提交。
其中在添加多行提交信息的時候，添加的方法和使用vim工具對文本文件進行編輯的方法是一致的，不會使用vim的朋友可以自行學習。
git log——查看提交日誌
git log是一個很重要的命令，使用它可以查看當前倉庫提交的日誌信息，通過日誌信息可以很方便查看何人在何時對代碼進行了提交和合並，以及提交前後的區別。
使用git log查看剛纔我們已經提交的兩次內容，如下圖所示：
上圖中顯示了兩次提交的詳細內容，包括commit id（黃色內容部分），也就是指向相應提交的HASH值，這個值是唯一代表本次提交，使用這個值可以輕鬆回退到指定的版本。上圖上還顯示了本次提交的作者和日期時間以及提交的時候編輯的具體提交說明內容。
- 查看簡短的提交日誌
有時候並不需要查看過多的提交日誌，那麼可以使用命令：
git log --pretty=short來查看簡短的提交日誌，如下圖所示：
- 只顯示指定文件或者文件夾提交日誌
有時候只想查看單個文件或者指定文件夾的提交日誌，可以使用命令
git log 文件名/文件夾名來進行查看，如下圖：
- 查看文件的改動內容
查看文件的具體的改動，可以添加-p參數來查看，具體命令如下：
git log -p [文件名/文件夾名]其中方括號中的內容是可選內容，填寫了就表示查看指定文件的改動。
從上圖可以看出，最近一次提交相對於前一次提交，增加了一行內容主分支master第一次編寫內容，且顯示第一次提交是新建的文件。
git diff——查看更改前後的差別
git diff可以查看工作樹、暫存區（index）、最新提交（HEAD）之間的差別，可以使用該命令實現查看自己在代碼中到底修改了一些什麼內容，它也是一個非常重要的常用命令。
- 查看工作樹和暫存區的差別
我們在README.md文件中再添加一行內容，並將其添加到暫存區中，然後再次修改README.md文件，使用git diff命令查看工作樹和暫存區之間的差別。
README.md已有的內容爲：
可以在後面在再添加一行內容：主分支master第二次編寫內容。然後將它添加到暫存區中，然後再次修改README.md文件，添加一行內容：主分支master第三次編寫內容。這次不再添加到暫存區，使用命令查看更改前後的差別。
從上圖可以看出，工作樹中的README.md文件的內容相較於暫存區多了一行。我們再次將README.md文件添加到暫存區中，然後使用命令git diff進行比較，結果沒有任何顯示，說明工作樹中的文件和暫存區中的沒有差別。
- 查看工作樹和最新提交的差別
使用命令git diff HEAD就可以查看工作樹和最新提交的差別，緊接着上面的操作，我們將暫存區中的最新更改提交到本地倉庫中，然後嘗試查看工作樹和最新提交的差別，結果同樣是沒有任何差別，這也是很容易想象的。那麼我們對工作樹中的README.md文件進行修改，不添加到暫存區也不提交，然後在嘗試進行查看。
我們修改了工作樹中的文件，而沒有添加到暫存區，所以使用git diff HEAD和git diff命令都是指向了工作樹與最新提交的差別。
三、分支操作
使用Git來進行代碼託管，主要是爲了方便團隊和合作開發，並行開發。在並行開發過程中，往往存在多個分支，且各個分支的代碼的進度都不一樣，開發的內容也不一致，比如develop分支是開發分支，feature是新功能開發分支，master是主分支。對於分支的操作，大多都是新建分支、切換分支、合併分支等。
各個分支完全可以獨立開發，等分支作業完成之後，再與主分支mater合併，共同推進項目前進。
- git branch——查看分支
使用git branch命令可以查看本地分支，如果想查看遠程分支，可以在後面加上參數-a。
如上圖所示，本地分支有且僅有一個master主分支，前面的*表示我們當前正在master分支上進行開發。
- git checkout -b——創建、切換分支
如果以當前分支master爲基礎創建新的分支，那麼使用命令：
git checkout -b 新分支名稱 [master]這是一個創建分支的並切換到新分支的一個命令，後面中括號的內容可以省略，默認是以當前分支爲基礎，創建新的分支，其中master可以換成遠程分支，這樣就可以在本地以遠程分支爲基礎創建一個新的分支。僅僅是切換分支，使用git checkout 分支名稱即可。上面的創建分支的命令可以換成兩行來進行：
git branch 新分支名稱
git checkout 新分支名稱現在使用命令來創建新的分支：
上面的命令是創建的了新的分支並切換到了新的分支上，我們可以使用git branch命令來查看本地分支：
切換到了新的分支，可以通過git status來查看當前分支的狀態，因爲是基於master創建的分支，所以當前分支也有master分支對應工作樹中的最新文檔。
- 特性分支
特性分支一般都是爲了完成某項特殊功能的分支，特性分支大多都是從主分支上新建而來，特性分支開發完成之後合併到主分支上。
- 主幹分支
在實際的項目開發中，master往往擔任着主幹分支的職責，主幹分支往往是穩定的分支，可以部署到正式的環境中。
- git merge——合併分支
我們對之前創建的新分支feature-A中添加部分內容（添加的內容不影響其他分支），然後添加到暫存區，再提交到本地倉庫，最後將其合併到主分支中。合併到哪個分支，首先就需要切換到哪個分支上，我們需要切換到master分支上，然後在進行合併。
上面合併使用到的命令是git merge 被合併的分支名，但是這裏推薦使用git merge --no-ff 被合併的分支名這個命令，因爲後者可以將合併記錄到歷史中，方便後面使用給git log --graph進行查看。
如果合併完想撤銷合併，只要合併後沒有進行添加索引和提交，那麼可以使用git checkout 文件名或者git checkout .來撤銷合併，如果添加了索引，那麼可以使用git rm --cached 文件名來撤銷添加索引。
- git log –graph——使用圖表方式進行查看日誌
git log不僅可以查看提交信息，還可以查看合併等信息，加上參數--graph可以使用圖標方式進行查看，在第一次合併，我們使用的是命令是git merge 被合併的分支名，這時候，使用git log --graph命令輸出的結果如下圖所示：
我們再次修改feature-A分支，再次合併，這次合併使用git merge --no-ff 被合併的分支名這個命令，此時在使用git log --graph命令進行查看：
可以清楚看見，分支合併的過程，這就是在合併時參數--no-ff的作用，--no-ff指的是強行關閉fast-forward方式，fast-forward方式就是當條件允許的時候，git直接把HEAD指針指向合併分支的頭，完成合並。屬於“快進方式”，不過這種情況如果刪除分支，則會丟失分支信息。因爲在這個過程中沒有創建commit。
四、更改提交的操作
- git reset——會退到歷史版本
更改提交操作也是常見的操作，這樣可以方便我們的代碼回退到某一個時間節點，對於已經提交到本地倉庫的分支，如果要撤銷提交或回退版本，常見的有三種方式，--mixed、--soft、--hard。那麼，對於這三種方式，到底有什麼區別呢？
git reset --mixed [commit id或者HEAD]：此爲默認方式，不帶任何參數的git reset，即時這種方式，它回退到某個版本，只保留源碼的修改，回退掉commit和index信息。git reset --soft [commit id或者HEAD]：回退到某個版本，只回退掉了commit的信息，不會恢復到index一級。如果還要提交，直接commit即可。git reset --hard [commit id或者HEAD]：徹底回退到某個版本，本地的源碼也會變爲上一個版本的內容，此命令慎用！
最常用的是第一種默認方式，風險最小，靈活性更高，以上三種回退方式比較重要，建議牢記。
現在一起來做一個小任務，共同學習一下如何來操作歷史版本，首先，我們將工作樹、暫存區、最新提交都恢復到feature-A創建之前，然後再基於master分支創建一個fix-B分支，然後切換到fix-B分支並添加部分內容並提交，然後在恢復到feature-A合併之後，然後將fix-B分支合併到主分支上。所以，我們最終需要的結果是：
我們使用命令和commit id切換到指定的歷史版本中，提交日誌是：測試工作樹和最新提交的差別，使用命令：
git reset --hard 316598977bb36a977304dacdf2a48be90f820d3c其中HASH值是與各自的環境相關，使用命令的時候需要更改爲自己的HASH值。
因爲使用的--hard參數，所以工作樹、暫存區、HEAD都切換到了這個歷史提交版本，查看README.md內容爲：
此時創建一個新的分支fix-B，並在該分支中添加部分內容並提交：
此時各分支的狀態是：
我們再將分支恢復到feature-A合併後的狀態，也就是如下圖所示：
因爲此時我們所處的狀態是在feature-A與主分支master合併之前，所以要恢復到feature-A，相當於將歷史版本向前推進，也就是“穿梭到未來”。由於命令git log只能查看以此時爲重點的操作日誌，無法查到未來的操作日誌，所以我們需要使用另外一個命令來查看，git reflog命令就是我們需要的命令。
上圖中黃色的內容都是HASH值的一部分（4位以上都可以直接參與執行），所以我們切換到master分支來恢復到feature-A與master合併的時刻。
我們再將fix-B分支合併到主分支master上來：
從上圖可知，系統告訴我們自動合併失敗了，原因是發生了衝突，需要我們自己手動解決衝突，然後提交結果。我們使用編輯器打開README.md文件，顯示的內容如下所示：
=======是合併前與合併後的分界線，我們需要將文件中的內容修改成爲我們需要的樣子並提交修改後的結果，修改完成之後的結果是：
解決完衝突以後需要添加到暫存區後，完成提交。
- git commit - -amend——修改提交信息
當我們第一次提交代碼的時候，提交信息可能是完全根據我們自己的意願來寫的，但是呢，公司往往對代碼的提交信息的格式有要求，比如需要加上JIRA號等，所以我們偶爾會需要修改提交信息，那麼使用命令git commit --amend就可以了。使用該命令之後，就可以修改上一次提交的信息了，進入編輯器之後就可以修改其中的信息了。
再次通過日誌查看結果，提交信息成功修改了：
- git rebase -i——壓縮歷史
當提交完代碼之後，發現代碼的部分註釋或者其他不太緊要的內容有些錯誤，大多數人的做法是撤銷本次提交，再次修改後重新提交，其實還有一種比較常見的操作，那就是修改部分錯誤，重新提交，然後將這次提交包含到前一個提交之中，壓縮成一個歷史記錄，這樣的效果就是沒有多餘的提交記錄，看起來就是這個小錯誤從來沒發生過一樣。這個小技巧也是很常用的小技巧，我們來測試一下。
基於master分支創建一個新的分支叫feature-C，然後在其中添加一些內容，並認爲製造一些單詞拼寫錯誤在裏面，方便後面修改。
上圖中README.md文件最後一行的第一個單詞拼寫錯誤，但是我們使用命令git commit -am "創建feature-C分支"進行了一次性的添加索引和提交。
對於上面製造出來的錯誤，我們在本次進行修改並提交：
由於這個分支進行了兩次提交，所以在歷史記錄中就有兩次提交的記錄，但是對於第二次提交，健全的歷史記錄並不需要他們，所以我們希望將這兩次提交歷史合併成爲一次歷史，那麼使用Git的相關命令輕鬆可以做到。首先我們查看兩次提交的歷史記錄：
我們使用命令git rebase -i HEAD~2來將兩次提交合並，鍵入命令之後，會打開編輯器，我們將第二次提交的記錄前面的pick改成fixup即可，就完成了兩次提交記錄的合併，後面可以通過查看日誌來確認一下。
修改完成之後，就會出現最後一行的溫馨提示：
我們再次查看日誌：
發現兩次提交成功合併成爲一次提交了，且這次提交的commit id也不和之前的都一樣了。最後我們切換到master分支將feature-C合併上來。
五、推送至遠程倉庫
以上的操作都是在本地操作的，作爲分佈型版本管理系統，我們需要將本地倉庫的代碼推送到遠程倉庫，方便其他成員協同開發，這裏採用的遠程倉庫是國產代碼託管平臺碼雲，至於其他平臺，如全球著名的“同性交友網站”——GitHub，操作方法和原理都是一致的。
我們在碼雲上建立一個公有倉庫，由於我們本次示例都是使用的README.md文件，所以在建立倉庫的時候，倉庫名稱需要和本地一致，且不需要使用README.md文件來記錄遠程倉庫的信息，假設讀者已經建立好了倉庫，且倉庫名稱和本地倉庫名稱一致。接下來我們將設置遠程倉庫中。
git remote add origin git@gitee.com:itlemon/git-test.git其中，[email protected]:itlemon/git-test.git來自碼雲上我們建立的公共倉庫，如下圖所示：
使用上面的命令之後，Git會自動將[email protected]:itlemon/git-test.git遠程倉庫的名稱設置爲origin（標識符）。那麼我們下次推送或者切換到遠程分支的時候加上origin標識符就相當於告訴Git，我們要推送到遠程倉庫或從遠程倉庫切分支到本地倉庫。
接下來，我們將README.md文件推送至遠程倉庫，使用命令：
git push -u origin master在第一次推送的時候，可能會遇見各種問題，比如沒有權限推送、遠程倉庫和本地倉庫有衝突等等，對於沒有權限推送，多數是因爲沒有創建公鑰，那麼我們需要在本地Git倉庫創建公鑰，然後將它設置到碼雲上，對於第一次推送有衝突，那麼可以在上面的命令中添加一個參數-f來強制推送即可（後期不建議使用強制推送，因爲會覆蓋遠程倉庫）。上述命令中-u參數是將origin master分支設置爲本地master分支的上游（upstream），這樣方便以後拉取代碼直接使用命令git push，而無需使用git push origin master，最後推送的效果是：
從上圖可以看出，本地的11次提交在遠程倉庫也可以進行查看，如下圖所示：
六、從遠程倉庫獲取
對於新入職的員工來說，安裝完Git，配置完權限，第一步基本都是被告知需要自己將代碼從遠程倉庫克隆下來，那麼如何克隆，那麼我們需要使用命令：
git clone git@gitee.com:itlemon/git-test.git使用git clone命令之後，我們在本地就建立了一個本地倉庫，默認處於master分支，那麼我們可以靈活查看遠程倉庫的各個分支，使用命令：
git branch -a也就是相較於查看本地分支列表，多了一個參數-a，假設我們遠程有一個feature-D分支，那麼怎麼把它從遠程倉庫切到本地？第一次切換和創建本地分支命令一致，例如：
git checkout -b feature-D origin/feature-D第一次將feature-D分支同步到本地，我們需要建立一個新分支來承載它，通常命名和遠程分支的一致。對於以後拉取代碼，直接git pull即可，就可以將遠程最新的feature-D分支上的代碼拉取到本地。如果其中發生了衝突，那麼需要手動解決衝突並提交分支，在推送至遠程分支，始終保持遠程倉庫分支是最新的。
有時候我們從一個新的分支不能拉取代碼下來，或者使用git branch -a命令不能獲取剛剛在遠程創建的新分支，那多半是因爲本地緩存的遠程分支列表沒有更新，這時候需要更新一下遠程分支列表：
git remote update origin --prune其中origin是遠程倉庫的標識符，如果你的遠程倉庫標識符不是origin，需要改成自己的標識符，通常默認都是origin。
掌握了以上的比較常用的命令之後，基本上可以應付大多數工作了，至於在實際開發過程中，我們也許會很少用到命令，但是我個人認爲，熟練使用命令將幫助你理解在IntelliJ IDEA中各種代碼版本操作。以上基本上都是對git常見命令的介紹，並採用圖文的方式一步一步演示，希望對讀者有所幫助。接下來我將繼續出一篇結合IntelliJ IDEA來使用Git的文章，使用其圖形化界面來演示如何利用Git來高效地和同事合作開發，希望能幫助和我一樣的新人快速融入公司團隊中。