文章已託管到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 "mylifes1110@163.com"【郵箱】@檢視資訊：
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 -- 檔名命令--與檔名之間必須要有一個空格，不要寫錯！
| 無檔案放入工作區、無add、無commit（沒有任何檔案狀態） |
|---|
 |
| 將一個名為test.txt檔案放入工作區、無add、無commit（未跟蹤狀態） |
 |
| 將test.txt檔案add到暫存區、無commit（暫存狀態） |
 |
| 將test.txt檔案commit提交到master主分支（提交狀態） |
 |
| 修改test.txt檔案內容、無add、無commit（修改狀態） |
 |
| 將處於修改狀態的檔案add並commit提交後再次檢視檔案狀態就無任何檔案狀態了！ |
2.8 撤銷修改命令操作
@工作區撤銷： 執行
git checkout -- 檔名命令可以撤銷到最近一次git add或git commit的狀態工作區撤銷內部流程： 你執行了工作區撤銷命令，如果暫存區有此檔案，則將暫存區中的檔案恢復到工作區中；如果暫存區沒有此檔案，則將分支中的檔案恢復到工作區中
@暫存區撤銷： 先執行
git reset HEAD 檔名命令將該檔案移除暫存區，後執行git checkout -- 檔名命令回退到上一個版本暫存區撤銷場景： 如果在工作區中修改了檔案併傳送到了暫存區中，但檔案中有需要撤銷的內容
三、分支
3.1 分支概述
- 每一個被git管理的倉庫都會有一個預設的主分支（master分支）
- 分⽀中接收
git commit提交的內容，為⼀個⼀個不斷向前發展的提交點。每個提交點都儲存了⼀個版本- 每個分⽀，都有⼀個指標，指標預設指向最近⼀次提交的版本
- ⼯作區中的內容，初始狀態，就是指標所指向的版本狀態
- 基於指標指向的版本程式碼，在⼯作區中做進⼀步的編碼，功能完成後，即可
git commit，在分⽀中形成新的提交點。然後再在⼯作區中，新增新程式碼，功能完成，再 git commit,⼜形成新的提交點，指標再次後移。如此反覆，不斷開發，不斷記錄版本。- 當有需要時，可以回退指標到某個提交點，在⼯作區中即可得到之前的某個版本的程式碼
| 分支效果圖 |
|---|
 |
3.2 多分支
為什麼要使用多分支呢？那麼我們就需要了解幾個場景了
場景1： 在編寫一個功能程式碼時，需要一週的時間，在一週時間內可能會有多次提交，但最後的時候我們中間提交點的程式碼中發現有問題存在，那這些存在問題的提交點就摻雜在master主分支，使主分支變得十分混亂
場景2： 在編寫一個功能程式碼時，有一個新的思路，但不確定能否最總實現預期功能效果，只能試著編寫，最後發現達不到預期功能結果，則中間提交過的很多提交點都無效了，也使得主分支變得十分混亂
場景3： 如果該專案是多人協同開發，master主分支有錯誤或無效的提交點會影響其他人的開發進度
注意： 實際開發中master分⽀儘量只存放穩定的程式碼提交，保證master分⽀穩定，有效。因為這樣保證了我們的開發進度不會受到影響
解決方案1： ⼀直不提交，等所有都寫完後，提交⼀次。雖然可以保護master分⽀，但開發過程中缺乏版本控制點，易丟失⼯作
解決方案2： 在需要編寫新功能時，新建⼀個開發⽤的分⽀，所有改動都在該分⽀上提交，在功能完整實現後，將該分⽀的最終內容合併到master分⽀。這樣，既保證開發中有多個版本可以控制，⼜保證master分⽀是穩定，有效的
| 多分支效果圖 |
|---|
 |
3.3 多分支基本命令操作
@建立分支： 使用
git branch 分支名命令建立分支，會與當前分支保持同樣的資料狀態，即新分支和當前分支指向同一個提交點@切換分支： 使用
git checkout 分支名命令切換分支，切換分支後工作區中顯示當前分支內容（切換分支實際上是切換了分支的指標，讓指標指向了所要切換到分支）@檢視當前分支： 使用
git branch命令來檢視當前分支@檢視當前分支詳細資訊： 使用
git branch -vv命令檢視分支詳細資訊，分支資訊則是所跟蹤的遠端分支資訊以及是否領先遠端分支等等@合併分支： 如果新分支編寫完成後，先使用
git branch master命令切換到master分支，再使用git merge 新分支名命令將新分支合併到master分支。此次合併就是將master的指標移到了新分支的位置，等價於快速合併
@檢視當前合併分支： 分支合併後可以使用git branch --merged命令檢視被當前分⽀合併了的分⽀@刪除分支： 將分支合併後，如果新分支不再繼續使用，可以先使用
git branch --merged命令檢視合併分支以確認我們即將刪除的分支的確是無用分支後，再使用git branch -d 分支名命令刪除需要刪除的無用分支。
3.4 解決分支衝突
場景： 建立一個新分支（見圖1）；切換到新分支，並在檔案中新增一些資訊並提交（見圖2）；切換到master分支，並在檔案中也新增一些資訊並提交（見圖3）；在master分支中合併新分支。此時合併分支中會出現衝突（見圖4）
分支衝突原因： 兩個分支對同一個檔案做了改動，所以在合併時git會無法確定保留哪個分支上的資料
@終止合併分支： 當出現分支衝突時可以使用
git merge --abort命令來終止合併分支@避免因為空⽩導致衝突： 在合併分支時，如果有空白內容有可能會出現分支衝突現象，所以此時可以使用
git merge 分支名 -Xignore-all-space命令來避免因為空白而導致的分支衝突解決分支衝突： 需要找到提交兩個分支的人一起討論最終保留哪些資料，討論後將最終要保留的資料在一個的分支中提交。此時便解決了合併時發生的分支衝突問題，合併完成後某個分支將不再使用可以使用
git branch -d 分支名命令來刪除無用分支注意： 解決衝突要麼保留其中的一方，要麼達成協議商討雙方手動合併，無論如何記得刪除
<<<< ==== >>>>這些符號
| 分支衝突效果圖 |
|---|
 |
| 分支衝突錯誤提示資訊： |
Auto-merging test.txt CONFLICT (content): Merge conflict in test.txt Automatic merge failed; fix conflicts and then commit the result. |
合併衝突後git將雙方對檔案的改動都保留了，並使用<<<<、======、>>>>>做了分隔 |
 |
3.5 快照
git在儲存每個版本時( 對應提交點 )，並不是複製所有⽂件，沒有改動的⽂件只是記錄⼀個連結。
解釋： 首先看V1版本內有三個檔案。我們將A、C檔案做了修改並提交便生成了V2版本。這時內部是怎麼操作的呢？其實git在內部複製了A、C兩個需要修改的檔案到V2版本中並做了修改，而虛線框中的B檔案並沒有發生任何修改，其git內部就以連結的形式在V2版本用引用了B檔案，減少了重複檔案的環節，大大提高了Git的效率。以此類推，以後的版本虛線框內也都是引用的上個版本的檔案
| 快照效果圖 |
|---|
 |
3.6 合併方式
分支的合併方式有兩種快速合併 和三方合併
- 快速合併內部流程： 一個人在主分支上拉出了一個新分支為newBr並提交了一次（移動了一次指標）。如果合併這兩個分支，在快速合併中只需要移動master分支的指標指向newBr分支即可實現合併
- 三方合併內部流程： 在三方合併中從開始分叉的那個提交點開始，分別將該提交點更新的部分資料合併至master和newBr分支，合併後就三個分支就剩下了倆個分支。則剩下的master分支和newBr分支將合併為一個新的提交點，而這個由三方合併成的新提交點為最終合併成功的那個master分支
注意： 以下例圖並不嚴謹，只為傳達思想！
| 快讀合併效果圖 |
|---|
 |
| 三方合併效果圖 |
 |
四、遠端倉庫（Github）
4.1 獲取SSH key
git本地倉庫和GitHub或碼雲之間傳輸，建議設定SSH key，避免在傳輸中反覆輸入密碼
設定SSH key： 執行
ssh-keygen -t rsa -C "郵箱"命令後的每一步都按Enter鍵確定就好，知道命令執行結束（-C 後面的內容隨意寫就行，這只是作為title而已）命令執行完畢後，會在你電腦的
C:\Users\主機名\.ssh目錄下生成金鑰檔案。id_rsa是私鑰，不能洩露出去。id_rsa.pub是公鑰，可以放⼼地告訴任何⼈。隨後註冊登入GitHub，在賬戶設定中選擇
SSH Keys，在Title中隨意填寫內容，在Key中填寫id_rsa.pub檔案中的所有內容在GitHub中新增好自己的公鑰，這樣和Git伺服器通訊時（clone，push，pull）git伺服器就可以識別出你的身份了！
4.2 註冊登入並設定SSHKey
GitHub官網地址： https://github.com/
| 註冊GitHub賬號（Sign up） |
|---|
 |
| 登入GitHub（Sign in） |
 |
| 右側頭像點選開啟Setting設定 |
 |
| 在Setting中建立SSH Key |
 |
| 新增SSH Key |
 |
4.3 建立遠端倉庫（主四步驟）
首先在GitHub中建立遠端倉庫，其次就是將本地倉庫關聯到遠端倉庫，這裡如果做關聯的話是需要執行一些命令的，雖然在GitHub建立倉庫的時候已經提示命令，但是由於我想到有很多小夥伴會不清楚怎麼看和執行這些命令，所以我在圖中已經標註。為了全面些，我也會把這些命令羅列到下方並作以解釋！
@新增自述檔案： 如果是本地倉庫是空的，我們需要建立一個自述檔案（README.md），也就是說建立一個檔案放入到本地倉庫中，執行
git add .和git commit -m "add a README.md"（最好倉庫中不是空的！）@關聯遠端倉庫： 關聯遠端倉庫只需要執行
git remote add 關聯別名 倉庫地址命令即可（注意：別名是可以自己取名設定的，但是不要忘記就好，因為後續push的時候會用到）@上傳到GitHub遠端倉庫： 執行
git push 關聯別名 master命令將檔案上傳到GitHub伺服器的主master分支上傳到GitHub遠端倉庫後，我們就可以正常的在GitHub檢視所上傳的檔案。設定一次關聯後，我們在本地倉庫上傳到GitHub遠端倉庫都需要
add -> commit -> push@檢視關聯的所有遠端倉庫： 執行
git remote -v命令檢視關聯的所有遠端倉庫@檢視關聯後遠端倉庫分支和本地倉庫分支的對應關係： 執行
git remote show 關聯別名命令檢視@刪除關聯： 執行
git remote remove 關聯別名命令刪除關聯@重新命名關聯別名： 執行
git remote rename 原關聯別名 新關聯別名命令重新命名關聯別名
| 右側頭像點選 + 後開啟New repository |
|---|
 |
| 建立倉庫 |
 |
| 本地倉庫關聯GitHub伺服器 |
 |
| 做完以上步驟就可以在GitHub上看到我們所上傳的檔案了！ |
4.4 上傳命令操作（push）
將本地倉庫的檔案上傳到關聯的GitHub遠端倉庫中顯示（注意：push的檔案是必須commit提交過的！）
將本地倉庫的檔案上傳到關聯的GitHub遠端倉庫中顯示（注意：push的檔案是必須commit提交過的！）
push操作需要關聯倉庫，也就是說必須有許可權來對GitHub遠端倉庫做操作，而且需要在你pull之後沒人push過
@上傳到GitHub遠端倉庫： 執行
git push 關聯別名 master命令來將本地倉庫的檔案上傳到GitHub遠端倉庫顯示（注意：我們是可以指定上傳的分支的！）@本地存在分支上傳GitHub分支： 執行
git push 關聯別名 本地倉庫分支:GitHub倉庫分支命令會將本地倉庫存在分支上傳到GitHub分支@本地存在多分支上傳到GitHub多分支： 執行
git push 關聯別名 本地倉庫分支1:GitHub倉庫分支1 本地倉庫分支2:GitHub倉庫分支2命令來實現一次性實現上傳指定多個分支
4.5 拉取遠端操作（fetch、merge）
拉取遠端倉庫的新內容到本地倉庫和版本庫，但是這個操作並沒有合併到本地庫的分⽀中，需要通過⼿動合併分支來實現。此操作並不常用，瞭解即可！
@拉取遠端倉庫分支： 執行
git fetch 關聯別名 master命令來拉取master分支下的內容@手動合併本地庫分支： 執行
git merge 關聯別名/master命令來手動合併本地庫分支下的內容上面兩個命令可以將GitHub伺服器上的最新狀態同步到本地倉庫中
@拉取所有分支： 執行
git fetch 關聯別名命令來拉取GitHub伺服器所有分支下的內容（合併分支如下）@手動合併所有分支內容： 執行
git checkout 分支1命令來切換分支並執行git merge 關聯別名/分支1合併拉取該分支的內容，並以此類推合併各個分支@比較拉取內容中的分支和本地分支中的不同： 首先執行
git checkout 分支命令來切換到想要比較並拉取的分支，再執行git diff 關聯別名/分支命令來比較拉取的內容中的分支和本地分支的不同
4.6 下載操作（pull）
首先下載操作等價於拉取遠端的新內容，併合併到當前分支的操作
@下載遠端內容： 可以執行
git pull 關聯別名 master命令來完成對遠端倉庫主分支內容的下載操作，該操作省略了本地倉庫分支（當前分支），預設的將遠端倉庫master主分支上的內容下載到了本地倉庫的master主分支@下載遠端內容的完整寫法：
git pull 關聯別名 遠端倉庫分支:本地倉庫分支（當前分支）
4.7 克隆操作（clone）
將GitHub遠端倉庫的所有內容下載到本地，該方式自動搭建了本地與GitHub遠端倉庫的關聯
@clone操作1： 執行命令
git clone SSH地址將遠端倉庫clone到本地，已設定key，不用命令@clone操作2： 執行命令
git clone HTTPS地址將遠端倉庫clone到本地，該方式需要輸入GitHub口令細節1： clone只在初次從git伺服器下載項⽬時執⾏⼀次，後續在需要同步應該執⾏pull或fetch
細節2： 當執⾏
git clone命令時，預設配置下遠端 Git 倉庫中的每⼀個⽂件的每⼀個版本都將被拉取下來
五、標籤
5.1 為什麼要打標籤
其實在我們做專案的時候是少不了遇見很多問題的，有可能在這個版本的問題釋出出現了問題，但是到了後面的幾個版本都沒有得到解決。而專案往往不會因為這些問題而終止專案的上傳。為了讓所有人能瞭解該版本中的問題而使用標籤作為標記
注意： 以下所使用的v1.1.0等等標籤是標籤名，小夥伴們可以根據自己的需求來打標籤
5.2 打標籤
@建立輕量標籤： 使用
git tag v1.1.0命令來建立輕量標籤@建立附加備註的輕量標籤： 使用
git tag -a v1.1.1 -m "說明文字"命令來建立附註標籤，而建立標籤會自動打在最近的提交點上@為以前的提交點打標籤： 如果為以前的提交點打標籤就需要使用
git log命令去檢視commitID，再根據commitID執行git tag -a v1.1.1 "commitID"來為該提交點打標籤
5.3 檢視標籤
@檢視所有分支上的所有標籤： 執行
git tag命令來檢視@檢視標籤名以“v1.1”開頭的標籤： 執行
git tag "v1.1*"命令來檢視@顯示標籤及其對應的提交資訊： 執行
git show v1.1.0命令來顯示標籤及其對應的提交資訊
5.4 共享標籤
標籤不會隨提交點⼀起 提交到遠端伺服器，需要單獨push。而pull時，標籤會⼀同被下載到本地
@同步一個標籤“v1.1.1”到GitHub伺服器： 執行
git push 關聯別名 v1.1.1命令來同步標籤@同步所有標籤到GitHub伺服器： 執行
git push 關聯別名 --tags命令來同步所有標籤
5.5 刪除標籤
標籤刪除需要在本地和遠端分別刪除
@在本地刪除標籤： 執行
git tag -d v1.1.1命令來刪除本地標籤@刪除遠端庫中的標籤： 執行
git push 關聯別名 :refs/tags/v1.1.1命令來刪除遠端庫中的所有標籤
5.6 標籤的使用
標籤的主要作用是用於釋出版本，假設我們已經為各個版本打了標籤“v1.0”、“v2.0”等等。現在需要v1.0版本，就可以分離一個指標指向v1.0版本的提交點位置
@原分離頭指標： 執行
git checkout v1.0版本的commitID命令來使頭指標指向該commitID的提交點@標籤分離頭指標： 執行
git checkout v1.0命令來使頭指標 指向該提交點注意： 分離頭指標只是一個臨時指標，它不歸屬任何分支，使用標籤顯然比使用commitID方便，最後隨意切一個分支，分離頭指標消失，就像之前什麼都沒有發生過一樣
六、別名
有一些指令感覺會比較麻煩，就可以定義別名來執行命令，簡化書寫。下面列舉一個常用的命令來實現別名的簡化
@簡化commit命令書寫： 執行
git config --global alias.comt "commit -m"命令來簡化commit -m命令，設定這種簡化命令之後以後執行git comt "描述資訊"命令就等價於執行了git commit -m "描述資訊"命令@刪除別名簡化： 執行
git config --global --unset alias.comt命令來刪除我們建立的簡化commit的別名，刪除後使用comt則就會失效
七、IDEA關聯Git
7.1 關聯Git
| 設定關聯Git |
|---|
 |
7.2 建立倉庫
在IDEA中建立倉庫之前，我們需要建立設定一個忽略檔案（.gitignore）。至於為什麼呢？那是因為我們在專案中會有很多檔案不必上傳，就比如db.properties配置檔案、.idea檔案、所有的.class檔案等等，所以這個忽略檔案就可以幫我們在上傳伺服器的時候忽略這些沒有必要的檔案，忽略後的檔案不會放在版本庫中管理
| 設定忽略檔案 |
|---|
 |
| 初始化一個倉庫 |
 |
 |
7.3 提交
| 選擇提交選單，提交一個版本 |
|---|
 |
| 選擇提交檔案，定義提交資訊 |
|---|
 |
| 之後會有些友好提示，可以忽略，點選“commit”即可 |
 |
7.4 建立分支
| 點選右下角連結，建立新分支 |
|---|
 |
| 新建分支 |
 |
| 檢視當前分支 |
 |
7.5 上傳到遠端倉庫
| 先建立一個倉庫，隨後選擇push選單 |
|---|
 |
| 定義遠端倉庫地址 |
 |
| 開始push操作 |
 |
| push成功後 ，彈窗提示 |
 |
7.6 複製到本地倉庫
| 找到GitHub或碼雲上的開源專案後複製連結，點選克隆選單 |
|---|
 |
| 輸入如遠端倉庫地址 |
 |
| 開啟專案 |
 |
| 開啟專案，選項 |
 |
7.7 更新本地專案
注意：如果遠端倉庫有更新，則你的本地專案也需要一起更新。
| 選擇pull選單 |
|---|
 |
| 執行pull操作 |
 |
| 更新日誌顯示 |
 |
7.8 IDEA中衝突解決
| 衝突出現，彈窗中可以選擇如下 |
|---|
 |
| 也可以直接修改衝突檔案，然後commit即可 |
 |
八、多人協同開發
8.1 專案經理
- 由專案經理負責建立一個遠端倉庫，初始倉庫中什麼都沒有，而庫的名稱建議和項⽬同名
- 管理員會在IDEA中建立⼀個空項⽬，其中包含 .gitignore⽂件 。並在項⽬根⽬錄下執行
git init建⽴本地庫，並建⽴dev開發分⽀- 管理員將本地庫同步到遠端庫，執行命令
git push 遠端庫地址 master:master dev:dev操作- 將專案組中的其他人員拉入遠端倉庫的開發人員列表中，此操作是賦予開發人員對遠端倉庫push等等的許可權
- master分⽀設定為 protected分⽀，只有管理員有許可權將程式碼合併到其中。dev分⽀設定為 常規分⽀所有開發⼈員都可以其中合併程式碼
注意： 管理員拉開發人員進入開發人員列表在倉庫的設定中設定
8.2 開發人員
- 開始的時候開發人員需要將專案使用IDEA或命令列clone遠端倉庫，獲取專案。clone操作自動關聯遠端倉庫並建立了本地倉庫
- 獲得項⽬時，本地庫中只顯示master分⽀，需要執⾏
git checkout dev即可獲得dev分⽀- 後續的開發中，都要在dev分⽀上進⾏。開發完⼀個功能並測試通過後就可以
git add .並git commit -m "描述資訊"提交到本地的dev分⽀中，然後git push遠端庫地址的dev分支並同步到遠端dev分⽀中- 如果在
git push遠端庫時，有⼈⽐你早⼀步git push，GitHub伺服器將拒絕你的git push操作。（樂觀鎖原理）不過很簡單，你需要先git pull遠端庫的dev分支後再git push即可