那些年，咱們玩過的Git

做者：玩世不恭的Coder
公衆號：玩世不恭的Coder
時間：2020-06-05
說明：本文爲原創文章，未經容許不可轉載，轉載前請聯繫做者

哪些年，咱們玩過的Git

前言1、前期工做經常使用基本概念的理解Git環境的搭建用戶名和郵箱的配置2、Git的理論基礎工做區域工做流程版本庫的初始化文件的四種狀態Git的初步操做3、關於文件的各類操做文件修改以後版本的回退撤銷修改文件的刪除4、本地項目遠程提交到Github倉庫5、Git的分支管理分支的建立與合併單人分支合併時的衝突解決多人協做下的衝突解決6、標籤管理總結參考資料

前言

關於Git，相信每一位該領域的朋友都瞭解其的強大。Git是一種廣受歡迎的代碼管理工具，在實際開發中，咱們能夠經過Git和團隊更好管理咱們的項目版本，也大大提升了團隊的開發效率。在實際使用Git的過程當中，咱們通常只須要掌握其中的十幾條命令就夠用了，Taoye以前對Git也只是停留在會用的狀態，而因爲對Git內部的一些細節平時接觸比較少，因此仍是會有一點盲區存在。因此，乘着考研結束的這段空閒時間，對以前學習過的Git作一個整理，一方面分享給各位讀者，另外一方面也方便本身往後的複習。本文主要介紹了在實際開發過程當中所經常使用的一些Git操做，因爲博主技術水平有限，在內容上的表述不免會有疏忽和遺漏，也懇請各位Coder多多指教。

1、前期工做

經常使用基本概念的理解

• 版本控制

所謂的版本控制是指對軟件開發過程當中各類程序代碼、配置文件及說明文檔等文件變動的管理，是軟件配置管理的核心思想之一。簡單的講，就是方便咱們對項目代碼的各類版本進行管理。

咱們能夠舉個例子來進行說明一下：相信每一位學生，不管是大學畢業或是研究生畢業，都避免不了完成一篇學術性的論文。咱們都知道，學術性論文的撰寫都是一個長期的過程，在這個過程也會經歷不斷地反覆修改，這樣就會產生多個論文版本。相信每一位有過此經歷的同窗都會感到痛苦，版本多了甚至都不知道每個版本的論文內容都修改了啥。而咱們的Git就可以很好的管理各類版本的論文，在每一次提交的時候，均可以在comment中記錄咱們對論文的修改內容，而且每個版本的論文均可以進行回滾等操做，也就是隨意的切換各類版本。如此一來，豈不快哉？？？

此外，咱們還可使用廖大大提到的例子來解釋一下：在許多遊戲中，都會有一個存檔的操做，若是你對接下來的挑戰Boss沒有足夠的信心，就能夠進行一次存檔，當咱們的角色由於挑戰Boss而喪命，咱們就能夠讀取其中的存檔而從當前狀態繼續遊戲，而不須要從頭再來，假如遊戲有保存多個存檔的操做，咱們還能夠讀取不一樣的存檔來繼續遊戲。一樣地，在咱們對文件進行修改到必定程度的時候，就能夠保存一個「快照」，一旦咱們對本身的操做的不滿意，就能夠進行恢復或是回滾操做，這樣就能夠「穿梭」到操做以前狀態繼續工做，而無需從頭再來。

• 工做區（Working Directory）

能夠理解成就是電腦本地磁盤的目錄，好比咱們在本地建立了一個temp目錄，那這個目錄就叫作工做區。

• 暫存區（Staging area）

通常存放在"git目錄"下的index文件（.git/index）中，因此咱們把暫存區有時也叫做索引（index）。

• 版本庫（Repository）

咱們的工做區有個隱藏目錄.git，它就是Git的本地版本庫。

對於以上部分概念，有些讀者可能不是很瞭解，你們能夠閱讀下面內容以後再回過頭來進行推敲，相信你們必定會有更加透徹的理解。

Git環境的搭建

對於Git的安裝，在前面咱們講解Hexo搭建博客的時候有介紹過，這裏咱們再簡單的回顧一下。

你可在git官網中根據本身的須要進行下載：git-scm.com/。打開以後你將看到以下內容，就無腦download for Windows：

將其下載到指定的磁盤，而後Windows系統下傻瓜式安裝便可。安裝好後咱們打開cmd終端（win+r -> 輸入cmd -> 回車），執行git --version，若出現git version 2.19.2.windows.1之類的版本輸出，那麼恭喜你已經成功安裝Git。

對於Linux操做系統下，咱們能夠直接經過命令的形式來進行安裝：

1# Linux下安裝Git
2sudo apt-get install git
複製代碼

用戶名和郵箱的配置

咱們在安裝完成Git以後，首先第一步要作的就是配置Git的用戶名和郵箱，這個是提交項目的用戶的惟一標識。

1# 配置用戶名和郵箱，配置好以後會寫入C:\Users\M的.gitfig文件中
2git config --global user.name "username"
3git config --global user.email "email@qq.com"
複製代碼

global說明：global表明全局的意思，也就是說咱們在以後提交的每個項目採用的都是該用戶名和郵箱。假如咱們須要在不一樣的項目中使用不一樣的用戶名和郵箱，咱們則不須要添加--global參數。

咱們將此信息配置好以後，就會寫入C:\Users\M中的,gitfig文件中。此外，咱們也能夠用過如下命令來查詢咱們所配置的用戶名和郵箱：

1# 查詢配置
2git config -l
複製代碼

2、Git的理論基礎

該部分的內容來自：www.cnblogs.com/best/p/7474…

工做區域

Git本地有三個工做區域：工做目錄（Working Directory）、暫存區(Stage/Index)、資源庫(Repository或Git Directory)。若是在加上遠程的git倉庫(Remote Directory)就能夠分爲四個工做區域。文件在這四個區域之間的轉換關係以下：

• Workspace：工做區，就是你平時存放項目代碼的地方
• Index / Stage：暫存區，用於臨時存放你的改動，事實上它只是一個文件，保存即將提交到文件列表信息
• Repository：倉庫區（或本地倉庫），就是安全存放數據的位置，這裏面有你提交到全部版本的數據。其中HEAD指向最新放入倉庫的版本
• Remote：遠程倉庫，託管代碼的服務器，能夠簡單的認爲是你項目組中的一臺電腦用於遠程數據交換

本地的三個區域確切的說應該是git倉庫中HEAD指向的版本

• Directory：使用Git管理的一個目錄，也就是一個倉庫，包含咱們的工做空間和Git的管理空間。
• WorkSpace：須要經過Git進行版本控制的目錄和文件，這些目錄和文件組成了工做空間。
• .git：存放Git管理信息的目錄，初始化倉庫的時候自動建立。
• Index/Stage：暫存區，或者叫待提交更新區，在提交進入repo以前，咱們能夠把全部的更新放在暫存區。
• Local Repo：本地倉庫，一個存放在本地的版本庫；HEAD會只是當前的開發分支（branch）。
• Stash：隱藏，是一個工做狀態保存棧，用於保存/恢復WorkSpace中的臨時狀態。

工做流程

git的工做流程通常是這樣的：

１. 在工做目錄中添加、修改文件；

２. 將須要進行版本管理的文件放入暫存區域；

３. 將暫存區域的文件提交到git倉庫。

所以，git管理的文件有三種狀態：已修改（modified）,已暫存（staged）,已提交(committed)

版本庫的初始化

咱們須要建立一個目錄來做爲咱們的項目根目錄，進入到該目錄以後，右鍵git bash來啓動git的操做窗口

1# 選擇對應的目錄，右鍵點擊git bash，而後建立一個目標項目目錄，並進入該目錄
2mkdir temp_project
3cd temp_project
複製代碼

以後，咱們須要將建立的目錄初始化爲Git所能識別倉庫，能夠經過git init來實現。初始化完成以後，就會在該目錄中自動建立出一個.git的隱藏目錄，關於咱們項目的版本信息都會存儲在該目錄當中。

1# 初始化一個倉庫，以後會多出.git隱藏文件
2git init
複製代碼

以上就是咱們自定義一個倉庫的過程。此外，咱們還能夠基於已經存在Git倉庫來進行操做，在Github中查找本身想要的Git倉庫，複製其連接，而後經過git clone來對該倉庫進行克隆，從而將該倉庫下載到咱們的本地目錄中：

1# 使用clone克隆Github中已經存在的倉庫
2git clone XXXXXX.git
複製代碼

文件的四種狀態

咱們要對文件的版本進行控制，首先須要明白當前文件處於什麼樣的狀態，對於不一樣狀態下的文件，咱們能夠進行不一樣的操做。而在Git中，文件主要是有四種狀態：

• Untracked: 未跟蹤, 此文件在文件夾中, 但並無加入到git庫, 不參與版本控制. 經過git add 狀態變爲Staged.
• Unmodify: 文件已經入庫, 未修改, 即版本庫中的文件快照內容與文件夾中徹底一致. 這種類型的文件有兩種去處, 若是它被修改, 而變爲Modified. 若是使用git rm移出版本庫, 則成爲Untracked文件
• Modified: 文件已修改, 僅僅是修改, 並無進行其餘的操做. 這個文件也有兩個去處, 經過git add可進入暫存staged狀態, 使用git checkout 則丟棄修改過, 返回到unmodify狀態, 這個git checkout即從庫中取出文件, 覆蓋當前修改
• Staged: 暫存狀態. 執行git commit則將修改同步到庫中, 這時庫中的文件和本地文件又變爲一致, 文件爲Unmodify狀態. 執行git reset HEAD filename取消暫存, 文件狀態爲Modified

Git的初步操做

瞭解了文件的狀態以後，咱們不妨模擬一個關於論文的例子來初步瞭解下版本庫以及文件的簡單操做：

• 建立一個工做區，並進行初始化

1# 建立一個工做區
2mkdir my_dir
3# 進入工做區
4cd my_dir
5# 經過init命令將工做區轉化成Git能夠管理的倉庫
6git init
7# 在該倉庫中建立一個paper.txt，用於編寫咱們的論文
8touch paper.txt
複製代碼

• 咱們在paper.txt之中編輯以下內容：

1# 咱們在`paper.txt`之中編輯以下內容：
2Oh, my god, I will write my graduate paper.
3Come on, Taoye.
複製代碼

• 經過add命令將paper.txt文件添加到暫存區

1# 經過add命令將paper.txt文件添加到暫存區
2$ git add paper.txt
複製代碼

• 經過commit命令將暫存區中的內容提交到倉庫

1# 經過commit命令將暫存區中的內容提交到倉庫，指定提交paper.txt文件
2$ git commit -m "start writing my paper" paper.txt
3
4# 對工做區中的文件統一提交至暫存區
5$ git commit -m "XXXXXXXXXXX"
複製代碼

使用commit命令以後，就能將咱們暫存區中的內容提交至倉庫中，其中的-m參數表示的是提交說明，用於解釋說明本次提價的內容。提交完成以後，咱們能夠在Git中經過git status來查看文件的狀態：

1# 查看指定文件的狀態
2git status paper.txt
3# 查看全部文件的狀態
4git status
複製代碼

以上操做過程以下圖所示：

3、關於文件的各類操做

文件修改以後

在上節中，咱們已經介紹了文件的四種狀態，而且以關於論文的例子來初步瞭解了版本庫以及文件庫的簡單操做。

假設如今論文指導老師對Taoye提出了要求：「Taoye同窗，時間來不及了，你今天必須給我完成論文的摘要部分！！！不然，後果自負！！！」

「Excuse me？今天？我遊戲打得正嗨呢。面對老師如此強硬的要求，沒辦法了，只能暫停上王者的上分階段了，開始剛論文。」對此，Taoye進行了一個騷氣的三下五除二操做，普遍的涉獵各類優秀的學者文獻並進行構思，迅速開寫paper.txt中的摘要部分，完成以後的內容以下所示：

1Oh, my god, I will write my graduate paper.
2Come on, Taoye!
3
4I have finished the summary today！
複製代碼

以後，咱們再經過git status命令來查看一下該論文文件的狀態：

1$ git status paper.txt
2On branch master
3Changes not staged for commit:
4  (use "git add <file>..." to update what will be committed)
5  (use "git checkout -- <file>..." to discard changes in working directory)
6
7        modified:   paper.txt
8
9no changes added to commit (use "git add" and/or "git commit -a")
複製代碼

此時，咱們能夠發現工做區中的內容發生了修改，而且與咱們上一次提交後版本庫中的內容不一致，這個時候，Git就會提醒咱們須要再次進行add、commit操做來將修改後的文件添加並提交至版本庫。另外，咱們也可使用diff命令來查看據上次提交所修改的內容：

1# 查看據上次提交所修改的內容
2git diff paper.txt
複製代碼

當確認文件修改的內容無誤以後，咱們就可使用add、commit操做來提交咱們的文件到版本庫中：

1# 添加至暫存區
2git add paper.txt
3# 提交至版本庫
4git commit -m "finished the summary" paper.txt
5# 查看狀態
6git status paper.txt
複製代碼

OK，Taoye從白天剛到深夜。如次一來，總算是完成了老師給的要求，興奮的將內容提交給老師審閱，而後又繼續打王者了。

版本的回退

Taoye連續打了12h的遊戲，有點累了。從新打開本身完美的論文欣賞一下，卻忽然發現有幾個錯別字，這種低級錯誤實屬不該該出現啊。思慮半刻，Taoye修改以後，再次add commit就完事了：

paper.txt修改以後的內容：

1Oh, my god, I will write my graduate paper.
2Come on, Taoye!
3
4I have finished the summary today！
5Some typos have been fixed.
複製代碼

再次add、commit操做：

1git add paper.txt
2git commit -m "fixed the typos" paper.txt
複製代碼

也就是說，如今咱們論文總共是有三個版本，分別是：初始化的論文、完成摘要的論文、修改錯別字後的論文。咱們能夠經過log命令來查看各類版本的論文文件：

1# 顯示各類版本文件的詳細信息
2$ git log paper.txt
3# 經過一行簡單顯示文件的信息
4$ git log --pretty=oneline paper.txt
5d7938315aa0f4a4d40c6a94a10ab8db25b50e23b (HEAD -> master) fixed the typos
6454cc579f0fe51fdfd97132384a9c5fcaa1993c2 finished the summary
7dc1dcd9501dec52e6160ce98bb5c118abb805289 start writing my paper
複製代碼

從以上log的輸出信息，咱們能夠知道所提交文件的全部歷史記錄，其中記錄了提交時間、提交做者（郵箱）、提交說明（-m）等信息。而且若是咱們仔細一看，會發現每個版本的文件都會對應一個commit id，這個id其實就至關於每個版本的惟一標識。好比，從上面的輸出結果，咱們能夠獲得第一個版本的commit id = dc1dcd9501dec52e6160ce98bb5c118abb805289，而這個commit id的做用就是方便咱們往後自由「穿梭」到各個版本（就是一種穿越時空的意思）。

Taoye的論文指導老師審閱了摘要內容以後，正言厲色的說道：「你這寫的啥玩意兒？牛頭不對馬嘴，並且竟然還有錯別字？」

沒辦法了，Taoye只能虛心接受老師的批評，再次苦逼的修改論文了。

咱們如今論文是版本三，有沒有一種快速有效的方法回退到版本一呢？？？在Git中，咱們能夠經過git reset --hard來實現這個需求，也就是版本的回退。版本的回退能夠用兩種形式，一種是經過HEAD來基於當前版本進行回退，另外一種是經過commit id來回退到指定的版本，其用法以下所示：

1# HEAD表示的是當前版本，能夠經過HEAD^回退到上一個版本
2git reset --hard HEAD^
3git reset --hard HEAD^^     # 回退到上上版本，回退到多少個版本以前就使用多少個^
4git reset --hard HEAD~50    # 回退到50個版本以前
5
6# 指定commit id來進行版本回退
7git reset --hard dc1dcd
複製代碼

值得注意的是，咱們經過指定id來進行版本回退的時候，因爲id過長，咱們不必全寫，只須要傳入前幾個字符保證id的惟一性便可。有使用過Docker的朋友，應該會熟悉，咱們在指定容器的時候，也是相似的操做。

下面Taoye版本三的論文迅速回退到版本一，騷操做以下：

1$ git reset --hard dc1dcd
2$ cat paper.txt
3Oh, my god, I will write my graduate paper.
4Come on, Taoye.
複製代碼

關於版本穿梭的簡單解釋：其實，在Git中，有個HEAD指針用於指向當前版本，當咱們進行版本回退的時候，其實就是改變HEAD的指向，指向對應的版本也就實現了版本的回退。這有點相似於數據結構中鏈表的操做。

此外，咱們還能夠經過git reflog來查看當前版本文件的變換：

1$ git reflog paper.txt
2dc1dcd9 HEAD@{1}: reset: moving to dc1dcd                       # 版本的回退（回退到版本一）
3d793831 (HEAD -> master) HEAD@{2}: commit: fixed the typos      # 第三次提交（版本三）
4454cc57 HEAD@{3}: commit: finished the summary                  # 第二次提交（版本二）
5dc1dcd9 HEAD@{4}: commit (initial): start writing my paper      # 第一次提交（版本一）
複製代碼

撤銷修改

假設Taoye在寫論文的時候，天天都在不斷地修修改改，內心面很是的煩躁，很不是滋味。因而乎，在paper.txt中添加以下一句話：

1I don't like my tutor, he often criticizes me.
複製代碼

然而，在打算提交的時候，想了想仍是有點不太妥，要是由於這麼一句話，最終致使沒法畢業那就完蛋了。對此，咱們在對文件commit以前使用'git status paper.txt'命令發現，能夠經過checkout --來進行修改撤銷，撤銷至修以前的狀態，操做以下：

1$ git checkout -- paper.txt
2$ cat paper.txt     # 執行以後，能夠發現已經撤銷到無最後一句的狀態
複製代碼

以上是發生在咱們對工做區中的文件進行修改，可是尚未執行git add操做，將工做區中的paper.txt添加至暫存區中的場景，已達到撤銷至修改以前的狀態。假設咱們在對paper.txt修改以後，再執行git add paper.txt命令將文件添加至暫存區，那麼咱們該怎樣撤銷呢？按照思路，咱們能夠先經過git reset HEAD將暫存區中的內容撤銷掉放回工做區，而後撤銷工做區便可實現需求，對此，有以下操做：

1# 將暫存區中的內容撤銷掉放回工做區
2git reset HEAD paper.txt
3# 撤銷工做區修改的內容
4git checkout -- paper.txt
複製代碼

如此一來，就完美的將I don't like my tutor, he often criticizes me.撤銷掉，Taoye也就能順利畢業了。關於撤銷，要記得與版本回退區分開來，撤銷是咱們在對文件進行修改可是尚未進行commit的時候發生的，而版本回退是在執行了commit提交操做以後發生的。

文件的刪除

在上面的內容中，咱們已經詳細的介紹了關於文件的修改、版本回退、撤銷等操做，下面咱們來說講文件在刪除以後應該會出現哪些操做。

假設如今出現了這麼一種狀況：Taoye有個頑皮的妹妹，她在用我電腦的時候，不當心將個人paper.txt論文文件從本地磁盤刪除了。一氣之下，Taoye將妹妹關進了小黑屋自我檢討七天。悲劇啊，Taoye忙活了將近一個月的論文就此煙消雲散，Git該如何挽回這樣的結局呢？

在paper.txt文件刪除以後，咱們使用git status來查看一下文件的狀態：

1$ git status
2On branch master
3Changes not staged for commit:
4  (use "git add/rm <file>..." to update what will be committed)
5  (use "git checkout -- <file>..." to discard changes in working directory)
6
7        deleted:    paper.txt
8
9no changes added to commit (use "git add" and/or "git commit -a")
複製代碼

在Git看來，你將文件從工做區中刪除，其實也是對文件的一種修改。也就是說，如今咱們的工做區中的內容與版本庫中的內容不一致（工做區沒有了paper.txt文件，而版本庫依然存在paper.txt文件）。爲了將二者空間中的內容達到一致，咱們如今有兩種選擇，一是將版本庫中的paper.txt文件刪除掉，二是將工做區中的paper.txt文件恢復。

有了以上的思路，咱們能夠有以下操做：

1# 將版本庫中的paper.txt文件刪除掉，須要執行commit纔會生效
2git rm -f paper.txt
3git commit -m "delete the paper.txt"
4
5# 將工做區中的paper.txt文件恢復
6git checkout -- paper.txt
複製代碼

對於文件的刪除，須要注意的是，只有提交到版本庫的文件，才能進行恢復，對於爲提交到版本庫的文件是沒法進行恢復的。

4、本地項目遠程提交到Github倉庫

Taoye在以前參加2019年騰訊微信小程序比賽的時候，開發了一個關於偵探推理的項目。Taoye如今想要將該項目從本地提交到Github，該如何實現呢？

咱們在實現該需求以前，首先須要將本地與Github進行聯通。對此咱們應該經過ssh在本地生成一個公鑰，而後在Github中配置該公鑰。操做以下：

1# 一、生成公鑰，執行以後會在.ssh目錄中生成祕鑰文件，其中id_rsa.pub表示的是公鑰
2cd ~/.ssh
3ssh-keygen -t rsa 26647879@qq.com
4# 二、進入github，settings -> SSH keys -> add key，而後將id_rsa.put中的公鑰複製進去
5# 三、配置好公鑰以後，須要驗證本地與github的連通性
6ssh -T git@github.com
複製代碼

在確認本地與Github聯通以後，咱們就能正常地將項目從本地遠程提交到Github中了。

• 登陸Github，建立一個目標倉庫，取名爲detective，用來存儲咱們的項目，並複製其中的.git連接地址
• 在Github建立倉庫以後，須要將該遠程倉庫與本地關聯起來

1# 在本地關聯目標倉庫，方便以後將項目推送至該遠程倉庫
2git remote add origin https://XXXXXX.git
複製代碼

• 進入咱們的本地項目，而後初始化爲git可管理的倉庫

1cd detective
2git init
複製代碼

• 將工做區中項目的全部文件添加至暫存區

1git add ./*
2
複製代碼

• 將暫存區中的內容提交到版本庫當中

1git commit -m "commit the detective project" ./*
複製代碼

• 將項目添加到版本庫以後，咱們就能夠將該項目推送至遠程倉庫了

1# 第一次推送
2git push -u origin master
3# 推送以後，若是咱們的項目發生了修改，咱們能夠不用在使用-u參數進行推送
4git push origin master
5
6# 另外，若是有須要的話，咱們還可使用clone命令將遠程倉庫克隆到本地
7git clone https://XXXXXX.git
複製代碼

5、Git的分支管理

分支是Git當中一個很是重要的概念，分支有點相似於樹枝，也就意味着爲了不影響主線的正常開發，咱們能夠將任務從主線中分離開來，從而造成一個分支，以後的任務都是在分支中來完成的，當任務完成以後，就能夠將完整的任務從分支提交到主線。

在前面版本回退一節當中，咱們知道，每一次的提交都會產生一個版本，屢次提交天然也就會產生多個版本。咱們能夠將每個版本看作是一個珠子，而多個版本就會經過一條線串聯起來，從而造成一條版本鏈。這個版本鏈其實就是一個master分支，也就是咱們上面所說的主線，咱們每一次的提交都是基於master分支來完成的，而HEAD指針則是用來指向當前分支（在沒有其餘分支的前提下，就是指向master）。

下面的圖文講解分支的內容，來自廖大大的教程：https://www.liaoxuefeng.com/wiki/896043488029600/900003767775424

一開始的時候，master分支是一條線，Git用master指向最新的提交，再用HEAD指向master，就能肯定當前分支，以及當前分支的提交點：

每次提交，master分支都會向前移動一步，這樣，隨着你不斷提交，master分支的線也愈來愈長。

當咱們建立新的分支，例如dev時，Git新建了一個指針叫dev，指向master相同的提交，再把HEAD指向dev，就表示當前分支在dev上：

你看，Git建立一個分支很快，由於除了增長一個dev指針，改改HEAD的指向，工做區的文件都沒有任何變化！

不過，從如今開始，對工做區的修改和提交就是針對dev分支了，好比新提交一次後，dev指針往前移動一步，而master指針不變：

假如咱們在dev上的工做完成了，就能夠把dev合併到master上。Git怎麼合併呢？最簡單的方法，就是直接把master指向dev的當前提交，就完成了合併：

因此Git合併分支也很快！就改改指針，工做區內容也不變！

合併完分支後，甚至能夠刪除dev分支。刪除dev分支就是把dev指針給刪掉，刪掉後，咱們就剩下了一條master分支：

分支的建立與合併

在上面，已經介紹了分支的概念及其斷鏈、成鏈的原理過程，下面咱們經過Git命令來完成分支的建立與合併。

在Git中，咱們能夠經過git branch來查看有哪些分支、git branch xxx來建立一個分支，其中帶有*號的表示當前分支、git checkout xxx來切換分支：

1# 建立一個名爲dev的分支
2$ git branch dev
3# 從master分支切換到dev分支中
4$ git checkout dev
5# 查看當前有多少分支
6$ git branch
7
8# 此外，咱們還實現分支的建立、切換這兩個操做合併執行
9$ git checkout -b dev
複製代碼

如今，咱們不妨在剛剛建立的dev分支中對paper.txt的內容進行編輯，在最下方添加這麼一句話：I'm writing the content of my paper.。編輯完成並保存以後，咱們提交到版本 庫，並再次切換到master分支，使用cat命令來查看paper.txt的內容。

1$ git checkout dev      # 切換到dev分支
2$ vim paper.txt         # 編輯paper.txt，並增添一句話
3$ git add paper.txt     # 添加到暫存區
4$ git commit -m "writing the content of this paper" paper.txt   # 提交到版本庫
5$ cat paper.txt         # 查看paper.txt內容
6$ git checkout master   # 再次切換到master分支
7$ cat paper.txt         # 查看paper.txt內容
複製代碼

採用cat命令兩次查看paper.txt內容時，咱們會發如今執行後一次命令時，paper.txt中的內容並無添加新增的一句話，這主要是由於咱們剛剛採用vim編輯paper.txt的時候是基於dev分支進行的，提交也是提交到dev分支，而非master分支，因此當咱們切換到master分支的時候並不可以看見paper.txt編輯後的內容。以下圖所示：

而咱們要想在master分支中查看到paper.txt的新內容，則須要將dev分支合併到master主分支中才行，採用的是git merge命令，操做以下：

1$ git checkout master
2$ git merge dev
複製代碼

合併完成以後，dev的任務已經完成了，也就沒有必要存在了，能夠經過git branch -d xxx來刪除分支：

1$ git branch -d env
2Deleted branch env (was e9c7421).
複製代碼

單人分支合併時的衝突解決

在編程的世界裏，多進程佔據了一個舉足輕重的地位。在高併發、高流量的場景下，咱們通常經過多進程來提升項目的服務效率，以便提升用戶體驗。話雖如此，可是在使用多進程的時候，許多問題一樣會慢慢浮出水面。一樣地，Git分支雖然可以方便多個的用戶協同開發，可是將多個不一樣內容的分支進行合併的時候卻會產生衝突，做爲一個對技術有追求的Coder，咱們應該要理解爲何會產生衝突，以及產生衝突後咱們應該怎樣解決。

出現衝突的場景：

1. 切換到dev分支後，對paper.txt進行編輯，而後將保存後的文件提交到版本庫中。
2. 切換到master分支，對paper.txt進行編輯，將保存後的文件提交到版本庫。
3. 在master分支下，將dev分支進行合併。

 1# 一、在dev分支中對paper.txt文件進行編輯，並提交到版本庫
 2git checkout dev
 3git vim paper.txt
 4git add paper.txt
 5git commit -m "the first operation" paper.txt
 6
 7# 二、在master分支中對paper.txt文件進行編輯，並提交到版本庫
 8git checkout master
 9git vim paper.txt
10git add paper.txt
11git commit -m "the second operation" paper.txt
12
13# 三、在master分支中，將dev分支合併
14git merge dev
複製代碼

此時，在咱們執行merge命令進行分支合併的時候，會出現以下內容：

1$ git merge dev
2Auto-merging paper.txt
3CONFLICT (content): Merge conflict in paper.txt
4Automatic merge failed; fix conflicts and then commit the result.
複製代碼

從如上Git給咱們提供的信息能夠知道，此時已經產生衝突，咱們必須手動解決衝突才能再次提交，使用git status paper.txt也能查看產生衝突的信息。咱們經過vim打開paper.txt文件能夠看見以下內容：

 1Oh, my god, I will write my graduate paper.
 2Come on, Taoye!
 3
 4I have finished the summary today！
 5Some typos have been fixed.
 6I'm writing the content of my paper.
 7<<<<<<< HEAD
 8
 9the second operation.
10=======
11
12the first operation.
13>>>>>>> dev
14
複製代碼

對此，咱們要想解決衝突，則須要在master主分支中手動編輯該文件，編輯並保存完成以後，在將文件提交到版本庫便可：

1vim paper.txt
2git add paper.txt
3git commit -m "solve the conflict" paper.txt
4
5# 查看分支的合併狀況
6git log --graph --pretty=oneline --abbrev-commit
複製代碼

下面原則來自廖大大的Git教程：https://www.liaoxuefeng.com/wiki/896043488029600/900005860592480
在實際開發中，咱們應該按照幾個基本原則進行分支管理：

1. 首先，master分支應該是很是穩定的，也就是僅用來發布新版本，平時不能在上面幹活；
2. 那在哪幹活呢？幹活都在dev分支上，也就是說，dev分支是不穩定的，到某個時候，好比1.0版本發佈時，再把dev分支合併到master上，在master分支發佈1.0版本；
3. 你和你的小夥伴們每一個人都在dev分支上幹活，每一個人都有本身的分支，時不時地往dev分支上合併就能夠了。

因此，團隊合做的分支看起來就像這樣：

多人協做下的衝突解決

如今導師給Taoye提出的新需求是：兩天內完成論文的初稿並提交。

Taoye大量的時間都花費在開黑中了，兩天內完成這個任務對Taoye來講有點困難。因而乎，Taoye想要找妹妹幫忙完成論文的part1部分，而本身完成part2部分。如此一來，兩個進程協同進行，也就能完美的實現了導師給的需求。妙哉，妙哉！Taoye心想到這，立馬提交本身論文的半成品到遠程倉庫，而後給妹妹提供一個git連接供其clone。

1# Taoye將本地論文提交到遠程倉庫
2$ git push origin master
複製代碼

1# 妹妹將遠程倉庫克隆到本地
2$ git clone XXXXXX.git
複製代碼

OK，既然兩人的本地都有了論文文件，那麼接下來就要開始並行完成各自的任務了，爲了不本身的操做給主分支帶來很差的影響，因而在master分支中建立一個dev分支用來編輯文件。因爲妹妹的效率比Taoye要快，因此率先完成了論文part1部分的內容，對此，妹妹有以下操做：

1# 妹妹的操做
2$ git branch dev
3$ git checkout dev
4$ vim paper.txt
複製代碼

而且在paper.txt添加內容：sister have finished the part1.，part1部分的內容完成以後，將dev分支迅速推送至遠程倉庫：

1$ git add paper.txt
2$ git commit -m "sister have finished the part1" paper.txt
3$ git push origin dev
複製代碼

OK，Taoye交給妹妹的任務已經完成了，因而就興奮的出去玩耍了。畢竟這篇論文是屬於Taoye的，因此仍是須要認真的完成，天然花費的時間也就更多了。經歷了一夜通宵的時間，終因而順利完成了part2部分的內容，因而屁顛屁顛的將論文提交至遠程倉庫：

1# Taoye的操做
2$ git checkout dev
3$ vim paper.txt
4# 在paper.txt添加一句：taoye have finished the part2
5$ git add paper.txt
6$ git commit -m "taoye have finished the part2" paper.txt
7$ git push origin dev
複製代碼

而就在Taoye推送論文到遠程倉庫的時候，因爲本身推送內容與妹妹推送的內容不一致，因此致使推送失敗。咱們經過Git給出的提示信息能夠知道，要想解決這個衝突，首先須要經過pull命令將最新的提交拉取下來，而後與本地合併，解決衝突以後再推送到遠程倉庫。爲此，Taoye立馬執行了pull命令：

1$ git pull
複製代碼

而在執行pull命令的時候，糟糕的問題又接踵而至了，Git提示說：There is no tracking information for the current branch.，也就是說本地的分支與遠程沒有創建連接。對此，咱們能夠創建連接後再執行pull命令：

1$ git branch --set-upstream-to=origin/dev dev
2$ git pull
複製代碼

雖然能夠執行pull命令，可是會出現衝突提示，因此咱們須要首先手動解決衝突，解決的方式和上節中同樣：對paper.txt文件進行編輯，而後提交併推送至遠程倉庫。因此，Taoye對paper.txt文件進行編輯以後，內容以下：

1taoye have finished the part1
2taoye have finished the part2
複製代碼

編輯好後，將文件保存並推送至遠程倉庫:

1$ git add paper.txt
2$ git commit -m "finished the part1 and part2" paper.txt
3$ git push origin dev
複製代碼

因此，在多人協做工做時咱們通常準守以下過程：

1. 完成任務後首先使用git push origin xxx推送至遠程倉庫
2. 若是推送失敗，則須要執行git pull命令將最新的提交拉取下來
3. 若是拉取失敗，則可能須要創建鏈接，因此執行git branch --set-upstream-to=origin/xxx xxx命令
4. 解決以後，再次執行git pull命令嘗試拉取最新提交
5. 此時，咱們須要對衝突文件進行修改，等到修改完成以後，將文件推送至遠程倉庫

6、標籤管理

在上面的內容中，咱們有介紹過，能夠根據版本號（很長的字符串）來實現任意版本之間的穿越。可是經過這種較長字符串版本號的形式對用戶並非特別友好，看的腦闊有點疼。因此咱們通常能夠給每個版本貼上一個標籤，而且能夠經過這個標籤來定位任意的版本，從而更加容易的實現版本穿越等需求。

在這，咱們也能夠將標籤看作是版本號的一個別名，使用標籤就至關於使用版本號，二者的做用是等價的。若是有使用過Docker的話，應該會知道，在Docker中，咱們每建立一個容器，Docker都會分配一個容器id以便於咱們定位對應的容器，而咱們本身也能夠爲每個容器定義一個別名。咱們在使用一系列的Docker命令對容器進行操做的時候，既能夠經過容器id，也能夠經過別名的形式來進行操做。

Git中，咱們主要是採用tag命令來管理標籤，因爲標籤比較的簡單，這裏就不一一講解了，與標籤相關的命令主要有如下一些：

 1$ git tag                       # 查看全部標籤
 2$ git tag v1.0                  # 沒有指定版本，則默認給當前版本打標籤
 3# 查看各個版本信息（版本號）
 4$ git reflog paper.txt | git log --pretty=oneline paper.txt
 5$ git tag v0.9 a35d6b           # 根據版本號來打標籤
 6# 打標籤的同時，給標籤添上相應的說明
 7$ git tag -a v0.1 -m "version 0.1 released" a35d6b
 8$ git show v1.0                 # 查看對應的標籤信息
 9$ git tag -d v0.9               # 刪除標籤
10
11$ git reset --hard v0.9         # 根據標籤實現版本穿越
複製代碼

總結

總的來說，Git上手仍是很快的，關鍵在於平時須要增強Git操做命令的訓練。以上關於Git的命令只是一部分，但若是掌握上述內容，仍是能夠輕鬆知足Git的實際需求的。若是有興趣想要了解更多關於Git的知識，能夠自行查閱相關的文檔或是書籍來進一步的學習。

參考資料

一個小時學會Git：www.cnblogs.com/best/p/7474…
廖雪峯Git教程：www.liaoxuefeng.com/wiki/896043…