萬字長文，手把手教你玩轉Git！

項目已託管到GitHub，你們能夠去GitHub查看下載！並搜索關注微信公衆號 碼出Offer 領取各類學習資料！

Git應用

---

1、初識Git

1.1 Git的簡史

同生活中的許多偉大事物同樣，Git 誕生於一個極富紛爭大舉創新的年代。

Linus在1991年建立了開源的Linux，Linux 內核開源項目有着爲數衆多的參與者。 絕大多數的 Linux 內核維護工做都花在了提交補丁和保存歸檔的繁雜事務上（1991－2002年間）。 到 2002 年，整個項目組開始啓用一個專有的分佈式版本控制系統 BitKeeper 來管理和維護代碼。 到了 2005 年，開發Samba的Andrew試圖crack 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官網下載：git-scm.com/

TortoiseGit官網下載：tortoisegit.org/

Git文檔下載：git-scm.com/book/zh/v2

Git詳細安裝教程參考：blog.csdn.net/weixin_4417…

注意： 關於Git的可視化工具下載與否取決於本身，筆者不建議下載可視化工具，由於咱們要大量使用並熟練使用命令來操做Git！

Git客戶端下載	Git可視化工具下載

1.7 安裝後測試

1.7.1 打開命令的兩種方式

1. Wins+R輸入cmd打開Dos命令窗口
2. 右鍵單擊打開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、倉庫

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、分支

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分支

注意： 如下例圖並不嚴謹，只爲傳達思想！

快讀合併效果圖
三方合併效果圖

4、遠程倉庫（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官網地址： github.com/

註冊GitHub帳號（Sign up）
登陸GitHub（Sign in）
右側頭像點擊打開Setting設置
在Setting中建立SSH Key
添加SSH Key

4.3 建立遠程倉庫（主四步驟）

首先在GitHub中建立遠程倉庫，其次就是將本地倉庫關聯到遠程倉庫，這裏若是作關聯的話是須要執行一些命令的，雖然在GitHub建立倉庫的時候已經提示命令，可是因爲我想到有不少小夥伴會不清楚怎麼看和執行這些命令，因此我在圖中已經標註。爲了全面些，我也會把這些命令羅列到下方並做以解釋！

1. @添加自述文件： 若是是本地倉庫是空的，咱們須要建立一個自述文件（README.md），也就是說建立一個文件放入到本地倉庫中，執行git add .和git commit -m "add a README.md"（最好倉庫中不是空的！）

2. @關聯遠程倉庫： 關聯遠程倉庫只須要執行git remote add 關聯別名 倉庫地址命令便可（注意：別名是能夠本身取名設置的，可是不要忘記就好，由於後續push的時候會用到）

3. @上傳到GitHub遠程倉庫： 執行git push 關聯別名 master命令將文件上傳到GitHub服務器的主master分支

4. 上傳到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、標籤

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方便，最後隨意切一個分支，分離頭指針消失，就像以前什麼都沒有發生過同樣

6、別名

有一些指令感受會比較麻煩，就能夠定義別名來執行命令，簡化書寫。下面列舉一個經常使用的命令來實現別名的簡化

@簡化commit命令書寫： 執行git config --global alias.comt "commit -m"命令來簡化commit -m命令，設置這種簡化命令以後之後執行git comt "描述信息"命令就等價於執行了git commit -m "描述信息"命令

@刪除別名簡化： 執行git config --global --unset alias.comt命令來刪除咱們建立的簡化commit的別名，刪除後使用comt則就會失效

7、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、多人協同開發

8.1 項目經理

1. 由項目經理負責建立一個遠程倉庫，初始倉庫中什麼都沒有，而庫的名稱建議和項⽬同名
2. 管理員會在IDEA中建立⼀個空項⽬，其中包含 .gitignore⽂件 。並在項⽬根⽬錄下執行git init建⽴本地庫，並建⽴dev開發分⽀
3. 管理員將本地庫同步到遠程庫，執行命令git push 遠程庫地址 master:master dev:dev操做
4. 將項目組中的其餘人員拉入遠程倉庫的開發人員列表中，此操做是賦予開發人員對遠程倉庫push等等的權限
5. master分⽀設置爲 protected分⽀，只有管理員有權限將代碼合併到其中。dev分⽀設置爲 常規分⽀全部開發⼈員均可以其中合併代碼

注意： 管理員拉開發人員進入開發人員列表在倉庫的設置中設置

8.2 開發人員

1. 開始的時候開發人員須要將項目使用IDEA或命令行clone遠程倉庫，獲取項目。clone操做自動關聯遠程倉庫並創建了本地倉庫
2. 得到項⽬時，本地庫中只顯示master分⽀，須要執⾏git checkout dev便可得到dev分⽀
3. 後續的開發中，都要在dev分⽀上進⾏。開發完⼀個功能並測試經過後就能夠git add .並git commit -m "描述信息"提交到本地的dev分⽀中，而後git push遠程庫地址的dev分支並同步到遠程dev分⽀中
4. 若是在git push遠程庫時，有⼈⽐你早⼀步git push，GitHub服務器將拒絕你的git push操做。（樂觀鎖原理）不過很簡單，你須要先git pull遠程庫的dev分支後再git push便可