手把手教你玩轉Git
文章已託管到GitHub，大家可以去GitHub檢視下載！並搜尋關注微信公眾號 碼出Offer 領取各種學習資料！
Git應用
一、初識Git
1.1 Git的簡史
同生活中的許多偉大事物一樣，Git 誕生於一個極富紛爭大舉創新的年代。
Linus在1991年建立了開源的Linux，Linux 核心開源專案有著為數眾多的參與者。 絕大多數的 Linux 核心維護工作都花在了提交補丁和儲存歸檔的繁瑣事務上（1991－2002年間）。 到 2002 年，整個專案組開始啟用一個專有的分散式版本控制系統 BitKeeper 來管理和維護程式碼。 到了 2005 年，開發Samba的Andrew試圖破解BitKeeper的協議，隨後開發 BitKeeper 的商業公司同 Linux 核心開源社群的合作關係結束，他們收回了 Linux 核心社群免費使用 BitKeeper 的權力。 這就迫使 Linux 開源社群（特別是 Linux 的締造者 Linus Torvalds）基於使用 BitKeeper 時的經驗教訓，Linus僅僅使用了兩週的時間用C寫出了Git，開發出自己的版本系統，一個月之內，Linux系統的原始碼已經由Git管理了。 他們對新的系統制訂了若干目標：
- 速度
- 簡單的設計
- 對非線性開發模式的強力支援（允許成千上萬個並行開發的分支）
- 完全分散式
- 有能力高效管理類似 Linux 核心一樣的超大規模專案（速度和資料量）
自誕生於 2005 年以來，Git 日臻成熟完善，在高度易用的同時，仍然保留著初期設定的目標。 它的速度飛快，極其適合管理大專案，有著令人難以置信的非線性分支管理系統。Git迅速成為最流行的分散式版本控制系統，尤其是2008年，GitHub網站上線了，它為開源專案免費提供Git儲存，無數開源專案開始遷移至GitHub。
這時候是不是有很多小夥伴已經被Linus所驚訝到了呢？使用了兩週時間用C寫出了Git！
1.2 Git到底是什麼？
Git是一個開源的
分散式版本控制系統，可以有效、高速地處理從很小到非常大的專案版本管理
1.3 什麼是版本控制系統？
版本控制是指對軟體開發過程中各種程式程式碼、配置檔案及說明文件等檔案變更的管理，是軟體配置管理的核心思想之一。
1.3.1 版本控制系統的作用
版本控制最主要的功能就是追蹤檔案的變更。它將什麼時候、什麼人更改了檔案的什麼內容等資訊忠實地了記錄下來。每一次檔案的改變，檔案的版本號都將增加。除了記錄版本變更外，版本控制的另一個重要功能是並行開發。軟體開發往往是多人協同作業，版本控制可以有效地解決版本的同步以及不同開發者之間的開發通訊問題，提高協同開發的效率。並行開發中最常見的不同版本軟體的錯誤(Bug)修正問題也可以通過版本控制中分支與合併的方法有效地解決。
版本控制系統不僅為我們解決了實際開發中多人協同開發的問題，還提供了一些功能：檢入檢出控制 、分支和合並 、歷史記錄
檢入檢出控制：同步控制的實質是版本的檢入檢出控制。檢入就是把軟體配置項從使用者的工作環境存入到軟體配置庫的過程，檢出就是把軟體配置項從軟體配置庫中取出的過程。檢人是檢出的逆過程。同步控制可用來確保由不同的人併發執行的修改不會產生混亂。分支與合併：版本分支（以一個已有分支的特定版本為起點，但是獨立發展的版本序列）的人工方法就是從主版本——稱為主幹上拷貝一份，並做上標記。在實行了版本控制後，版本的分支也是一份拷貝，這時的拷貝過程和標記動作由版本控制系統完成。版本合併（來自不同分支的兩個版本合併為其中一個分支的新版本）有兩種途徑，一是將版本A的內容附加到版本B中；另一種是合併版本A和版本B的內容，形成新的版本C。歷史記錄：版本的歷史記錄有助於對軟體配置項進行稽核，有助於追蹤問題的來源。歷史記錄包括版本號、版本修改時間、版本修改者、版本修改描述等最基本的內容，還可以有其他一些輔助性內容，比如版本的檔案大小和讀寫屬性。 如果我們開發中的新版本發現不適合使用者的體驗，這時候就可以找到歷史記錄的響應版本號，回退到歷史記錄版本！
1.4 版本控制系統的分類（瞭解）
常見流行的分散式版本控制管理系統有Git
常見流行的集中式版本控制管理系統有CVS、SVN
| 代 | 網路 | 操作 | 併發性 | 示例 |
|---|---|---|---|---|
| 第一代 | 無 | 僅一個檔案 | 鎖定的 | RCS、SCCS |
| 第二代 | 集中式 | 多檔案 | 提交之前合併 | CVS、SourceSafe、Subversion、Team Foundation Server |
| 第三代 | 分散式 | 變更的集合 | 合併之前提交 | Bazaar、Git、Mercurial |
1.5 分散式與集中式
1.5.1 集中式
集中式系統是指由一臺或多臺主計算機組成的中心節點，資料集中儲存於這個中心節點中，並且整個系統的所有業務單元都集中部署在這個中心節點上，系統的所有功能均由其集中處理。簡單提了集中式的概念，那集中式版本控制也是如此。如圖，我們需要合併版本、更新版本時，是將各個版本上傳伺服器實現集中式合併！
舉例來說，集中式版本控制系統在公司中的使用，需要安裝一個Server（伺服器），然後各個使用版本控制系統的成員安裝客戶端，然後就是客戶端連線伺服器了，只有臉上這個伺服器才能做版本控制，如果連不上那就不行了。
工作流程： 比較熟悉的SVN是集中式的版本控制系統，每次在進行版本控制之前，需要先從中央伺服器（服務端）取出最新的版本，然後開始工作，工作完後推送給中央伺服器。此時的中央伺服器就好比是一個圖書館，如果你要修改一本書，需要先從圖書館借出來，然後回到自己家修改，改完之後，需要在送回到圖書館。
1.5.2 分散式
分散式系統是一個硬體或軟體元件分佈在不同的網路計算機上（本地化儲存），彼此之間僅僅通過訊息傳遞進行通訊和協調的系統。又一次簡單提了分散式的概念，那分散式版本控制更是如此。如圖，我們需要合併版本、更新版本時，各臺計算機都可以去實現彼此之間合併、更新，不再只依賴於一箇中心節點，為我們開發提供了靈活與便捷！
舉例來說，分散式版本控制系統在公司中的使用與集中式不同，各個成員需要安裝一個Git客戶端，而各個成員之間可以隨時隨地的實現版本控制（比如：兩個人合併後，再與第三個人合併或者小組與小組之間合併進行版本控制），不再依賴於必須連線伺服器才能實現，那麼我們實現了各個小組之間的靈活控制後，最終還是得落到了伺服器的手中。我們需要把各個成員、小組之間的版本控制結果，上傳到伺服器（GitHub）中進行最終合併！
工作流程： 分散式版本控制系統是沒有“中央伺服器”，每個人的電腦上都是一個完整的版本庫，工作的時候，不再需要聯網。開始工作前，在客戶端克隆出完整的程式碼倉庫，然後就可以在家、在公交車等等隨心所欲地修改程式碼並提交了，提交到本地電腦，等到有網的時候就可以一次性地將本地倉庫推送到遠端倉庫（臨時中心伺服器）中，這樣一來，每個人都可以獨立進行改動資料，並且所有的改動都是在完整資料資訊的環境下進行的。
1.5.3 分散式與集中式的區別
集中式
- 有一個單一的集中管理的伺服器，儲存所有檔案的修訂版本，所有程式碼庫。
- 對網路的依賴性強，必須聯網才能工作，上傳速度受網路狀況、頻寬影響。
- 客戶端記錄檔案內容的具體差異，每次記錄有哪些檔案做了更新，以及更新了哪些行的什麼內容。
缺點： 中央伺服器的單點故障。 如果中央伺服器發生宕機，所有客戶端將無法提交更新、還原、對比等，也就無法協同工作。如果磁碟發生故障，資訊尚無備份，還會有資料丟失的風險。
分散式
- 本地客戶機進行操作，離線工作，快速。
- 安全性高，每個人電腦裡都有完整的版本庫，如果電腦發生了更換複製一份就可以。
- 原子性提交，提交不會被打斷（git）。
- 工作模式非常靈活（傳統的集中式工作流 + 特殊工作流 + 特殊工作流和集中式工作流的組合）。
缺點： 缺少許可權管理、命令複雜混亂
1.6 Git的下載安裝
Git官網下載：https://git-scm.com/
TortoiseGit官網下載：https://tortoisegit.org/
Git文件下載：https://git-scm.com/book/zh/v2
Git詳細安裝教程參考：https://blog.csdn.net/weixin_44170221/article/details/104490352
注意： 關於Git的視覺化工具下載與否取決於自己，筆者不建議下載視覺化工具，因為我們要大量使用並熟練使用命令來操作Git！
| Git客戶端下載 | Git視覺化工具下載 |
|---|---|
 |
 |
1.7 安裝後測試
1.7.1 開啟命令的兩種方式
- Wins+R輸入cmd開啟Dos命令視窗
- 右鍵單擊開啟Git Bash Here視窗
1.7.3 命令檢視Git版本號
@檢視Git版本號：
git version
1.7.2 提交版本控制人資訊
安裝後開啟命令視窗，第一次需要提交我們的資訊，這樣可以讓我們在版本控制的時候知道是誰做的這一次的版本控制。畢竟合併、更新程式碼等是一件很重要的事，萬一缺失損壞了怎麼辦呢？是吧！
@提交資訊版本操作者資訊：
git config --global user.name "Ziph"【使用者名稱】
git config --global user.email "[email protected]"【郵箱】@檢視資訊：
git config -l
二、倉庫
2.1 倉庫是什麼？
版本庫又名倉庫，英文名repository，你可以簡單理解成一個目錄，這個目錄裡面的所有檔案都可以被Git管理起來，每個檔案的修改、刪除，Git都能跟蹤，以便任何時刻都可以追蹤歷史，或者在將來某個時刻可以“還原”。
2.2 基本結構
工作區： 由我們使用命令
git init初始化的一個本地資料夾，而初始化後的這個資料夾就被稱為工作區暫存區： 由我們使用命令
git add .把檔案新增到暫存區，而被新增的位置則是工作區中.git目錄中的index檔案，所以這也叫做索引版本庫： 工作區中會有一個隱藏的.git資料夾，這個不算是工作區，而是Git的版本庫，版本庫中記錄了我們提交過的所有版本，也就是說版本庫管理著我們的所有內容
分支： 版本庫中包含若干分支，提交後的檔案就會儲存在分支中，而開始的時候版本庫中只會有一個主分支master
| 基本結構 |
|---|
 |
| 工作區-版本庫-暫存區-分支 |
 |
2.3 倉庫基本命令操作
我們在使用git來管理本地倉庫時，每次對工作區中的內容做的任何變化都需要add（新增）和commit（提交）操作來同步git版本庫，只有做了新增和提交操作git才能管理我們的工作區。
@建立版本庫： 建立或找到一個資料夾，開啟命令視窗，執行
git init初始化本地工作區，在該工作區內會初始化生成一個.get目錄，而該目錄就是版本庫，它儲存著倉庫的所有資訊@新增一個檔案： 在工作區中放入一個檔案，然後在命令列視窗中執行
git add 檔名即可向工作區中新增一個檔案@新增多個檔案： 在工作區中放入多個檔案，然後在命令列視窗中執行
git add 檔名1 檔名2 ...即可向工作區中新增多個檔案@新增資料夾內容： 在工作區中放入一個資料夾，然而資料夾中有很多檔案，開啟命令列視窗執行
git add 資料夾名即可向工作區中新增該資料夾以及資料夾內的所有內容@新增工作區內所有內容： 如果工作區中有很多資料夾和檔案，我們一個或多個新增很麻煩，我們可以使用
git add .命令來新增工作區中的所有內容@提交某些檔案： 使用
git commit 檔名1 檔名2 -m "本次提交的描述資訊"，注意提交的描述資訊是為了記錄本次提交而方便查詢，所以儘量能明確反映本次提交@提交所有檔案： 使用
git commit -m "本次提交的描述資訊"命令來提交檔案，提交後的檔案就由git來管理了。-m 後面雙引號中的內容，這描述這次提交的資訊，以便以後我們後續找到這次提交再做操作@修補提交： 提交後發現有問題，比如釋忘記修改，⽐如提交描述不夠詳細等等。我們可以執行
git commit --amend -m"描述資訊"來再次提交替換上次提交@新增並提交檔案： 使用
git commit -a -m "本次新增並提交的描述資訊"命令來自動新增和提交所有檔案@刪除檔案： 使用命令
git rm 檔名來刪除檔案，並使用git commit 檔名 -m "描述資訊"來提交這次刪除的檔案（瞭解即可）@檔案刪除和修改： 關於向git提交後的檔案，刪除和修改我們只需要重新提交即可。也就是說，我們挪動或刪除了工作區中的檔案或更改了工作區中的目錄結構，都需要重新向git新增和提交你所變動的檔案。
@檔案狀態： 關於如何檢視我們新增或提交了哪些檔案、還是隻添加了檔案沒有把它提交。檢視檔案狀態需要使用
git status命令檢視檔案的狀態@檢視該檔案的改動情況： 使用
git diff 檔名命令來檢視該⽂件的改動情況@幫助： 使用
git help commit或者git commit --help來獲取命令的提示幫助
2.4 日誌命令操作
我們的每次提交，git都會隨著提交的變動來記錄版本變化，所以你在工作區中的所有操作都會留下日誌。
@檢視所有提交日誌： 使用
git log命令來顯示從最早的提交點到當前提交點的所有日誌@檢視執行條數的提交日誌： 使用
git log -數量命令來顯示最近指定數量條的提交日誌@簡潔日誌顯示： 使用
git log --oneline命令來顯示比較簡潔的提交日誌@檢視最近的2次提交日誌： 使用
git log --oneline -數量命令來簡潔的顯示最近的數量條的提交日誌@圖形化顯示分支走向： 使用
git log --oneline --graph命令來圖形化顯示分支走向提交ID： git中的commitID是通過SHA1計算出來的⼀個⾮常⼤的數字，⽤⼗六進製表示，在分散式中保證唯一性。
而關於日誌中顯示的commitID，使用
git log命令顯示的提交ID是很長的字串，而使用git log --oneline命令來簡潔顯示的提交ID是一個7位的字串。如果我們後續在使用commitID來操作的時候可以指定提交ID的前幾位字元即可，只要在你所操作的幾條commitID前幾位字元不發生重複就可以使用，所以在我們使用ID的時候並不需要使用很長的ID來操作，而一般使用前7位
| 檢視日誌 |
|---|
 |
2.5 版本回退命令操作
每次修改檔案並新增和提交。git都會記錄一個版本，如果有需要可以回退到之前的資料版本狀態
@回退上一個版本： 使用
git reset --hard HEAD~命令來回退到上一個版本@回退上上個版本： 使用
git reset --hard HEAD~~命令來回退到上上個版本@回退到上某數量個版本： 使用
git reset --hard HEAD~數量命令來回退到上某數量個版本@回退到某次提交時的版本： 使用
git reset --hard commitID命令來回退到某次提交時的版本注意： 回退的版本指定的commitID假如是22c4302cc866fbf5a3184b1fea6bd90b8c85255f，此時我們可以使用命令
git reset --hard 22c4302來回退到該提交ID時的版本，雖然commitID這麼長，我們只需要保證唯一性來輸入前幾位commitID即可。要記住回退版本並不會刪除任何版本，所以版本之間可以來回切換@細節： 發⽣版本回退後，通過
git log命令只能看到最原始提交點⾄當前提交點的⽇志。而git reflog可以看全部⽇志（包括版本回退的日誌）
2.6 檔案狀態
切換至某個分支，在工作區操作該檔案，檔案狀態會有以下幾種：
| 檔案狀態 | 描述 |
|---|---|
| 未跟蹤 | ⼯作區中新建立的⽂件，git中並未儲存它的任何記錄。使用git add .命令新增至暫存時即可建立跟蹤狀態 |
| 修改 | 已跟蹤狀態的檔案，在工作區被修改了，則會變為修改狀態 |
| 暫存 | 使用git add .命令新增到暫存區的檔案處於暫存狀態。每次暫存的是檔案的當前狀態，如果檔案被修改過，則需要再次將該檔案新增到暫存區。而每次提交，是將所有暫存區的檔案提交 |
| 提交 | 使用git commit -m "描述"命令來提交檔案，則該檔案就將從暫存狀態變為了已提交狀態。每次提交，會增加一個版本，分支指標後移指向新版本 |
2.7 檢視檔案狀態
我們可以使用
git status命令來時刻檢視檔案所在狀態@細節： 可以使用
git diff命令來比對工作區內檔案的變動狀態@比對： 使用
git diff 檔名命令來比對工作區和暫存區（若暫存區沒有則比對分支）@比對工作區與分支的最新結果： 使用
git diff HEAD -- 檔名命令來比對工作區和分支的最新結果@比對暫存區與分支的最新結果： 使用
git diff --staged 檔名命令來比對暫存區與分支的最新結果注意：
git diff HEAD -- 檔名命令--與檔名之間必須要有一個空格，不要寫錯！