文章已托管到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初始化本地工作區，在該工作區內會初始化生成一個.git目錄，而該目錄就是版本庫，它保存着倉庫的所有信息@添加一個文件： 在工作區中放入一個文件，然后在命令行窗口中執行
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即可