1、Git初識與安裝

假設今天你的老板讓你實現一份設計文檔，你做完之后將它發給你老板，老板說這做的不好，繼續改一下。這時候你進行了第一次修改，然后再發給他。老板還是覺得不好讓你繼續修改。這時候你進行第二次修改，如此往復直到第五次修改完之后，你老板說怎么改的還沒第一次改得好，你現在把第一次改的發給我吧。那么這時候就有問題了，你在改設計文檔的時候都是在原來那份上改的，現在你已經不知道第一次改的那份文檔是啥樣的了，所以你也就無法發給老板了。
那么現在還是修改設計文檔，第一次修改完之后你把這份文檔命名為設計文檔v1，當老板不滿意需要你繼續修改時，你就拷貝一份副本然后修改，最后命名為設計文檔v2。如此一直到設計文檔v5，當你的老板要你第一次修改的文檔時，你就可以將之前保存的設計文檔v1發給他了。但是隨著版本的不斷增多，維護好版本是很有挑戰的。而且各自版本修改的內容我們不一定能記得了。
所以就需要版本控制器：記錄每次修改以及版本迭代的一個管理系統。目前最主流的就是Git。
Git可以控制電腦上的所有格式的文檔，對于我們開發人員來說可以控制項目中的源代碼文檔。

還需要再明確一點，所有的版本控制系統，Git也不例外，其實只能跟蹤文本文件的改動，比如TXT文件，網頁，所有的程序代碼等等。版本控制系統可以告訴你每次的改動，比如在第5行加了一個單詞 “Linux”，在第8行刪了一個單詞 “Windows”。 而圖片、視頻這些二進制文件，雖然也能由版本控制系統管理，但沒法跟蹤文件的變化，只能把二進制文件每次改動串起來，也就是只知道圖篇從100KB改成了120KB，但到底改了啥，版本控制系統不知道，也沒法知道。

---

使用如下命令查看是否安裝了git：

git --version

CentOS可以使用以下命令安裝：

sudo yum -y install git

Ubuntu可以使用以下命令安裝：

sudo apt install git

---

2、Git基本操作

2.1、創建Git本地倉庫

要提前說的是，倉庫是進行版本控制的一個文件目錄。我們要想對文件進行版本控制，就必須先創建一個倉庫出來。創建一個Git本地倉庫對應的命令為git init ，注意命令要在文件目錄下執行。

創建后當前目錄下會多出一個.git的隱藏文件。

---

2.2、配置Git

當安裝Git后首先要做的事情是設置你的用戶名稱和e-mail地址，這是非常重要的。

git config [--global] user.name "Your Name"
git config [--global] user.email "email@example.com"
# 把 Your Name 改成你的昵稱
# 把 email@example.com 改成郵箱的格式，只要格式正確即可。

查看配置的命令為：

git config -l

想要取消配置可以使用如下命令：

git config [--global] --unset user.name
git config [--global] --unset user.email

其中--global是一個可選項。如果使用了該選項，表示這臺機器上所有的Git倉庫都會使用這個配置。如果你希望在不同倉庫中使用不同的name或e-mail，可以不要--global選項，但要注意的是，執行命令時必須要在倉庫里。

當我們使用了--global，那么直接--unset是無法移除配置的，需要同時攜帶--global和--unset。

---

2.3、認識工作區、暫存區、版本庫

我們在之前初始化倉庫目錄下創建要給ReadMe文件。目前情況下，Git能否管理ReadMe文件？答案是不行。

如圖，我們所在的gitcode實際上是工作區，而.git是版本庫，也就是我們所說的倉庫。那我們能直接把ReadMe放到.git目錄下進行管理嗎？答案是不行的，不允許在.git下手動修改！實際上我們需要經過兩步：1、git add將工作區修改的內容添加到版本庫的stage中，這個就是暫存區/索引。2、git commit將暫存區的內容提交到master分支下。通過這兩步才算是真正將內容放到了版本庫中。另外暫存區還會有一個對象庫objects，當我們修改工作區的內容會寫入對象庫中一個新的git對象。暫存區里面存放的就是對象庫中的git對象的索引，master也是如此，暫通過git commit會將暫存區中的內容添加到master中。暫存區是在.git/index下的，但是當前我們并沒有這個文件，因為我們是剛創建的倉庫，還沒有進行add。

? 在創建Git版本庫時，Git會為我們自動創建一個唯一的master分支，以及指向master的一個指針叫HEAD。（分支和HEAD的概念后面再說）
? 當對工作區修改（或新增）的文件執行git add命令時，暫存區目錄樹的文件索引會被更新。
? 當執行提交操作git commit時，master分支會做相應的更新，可以簡單理解為暫存區的目錄樹才會被真正寫到版本庫中。
由上述描述我們便能得知：通過新建或粘貼進目錄的文件，并不能稱之為向倉庫中新增文件，而只是在工作區新增了文件。必須要通過使用git add和git commit命令才能將文件添加到倉庫中進行管理！！！

那么下面就對我們創建的這個文件添加到版本庫中：

我們創建三個文件繼續添加：

通過git log查看提交日志信息：

commit后面的內容就是commit id，并且可以看到之前我們設置的name和email，以及提交的日期，HEAD指針是指向master的。

通過git log --pretty=oneline查看可觀的提交信息：

下面我們再看看.git目錄發生的變化：

我們發現果然多了一個index文件，這個就是上面所說的暫存區了。我們使用cat命令打印HEAD內容，發現它果然是指向master的，接著我們再打印master的內容，里面存放的就是最新的commit id。這個實際上就是一個git對象。

這個id我們需要分成兩個部分來看，前兩位80表示目錄，后面的就是文件了，對應右邊.git目錄結構所示。接下來我們需要使用git cat-file -p來查看這個git對象里面保存了什么信息。-p表示pretty，讓格式好看一些。
同時我們呢可以注意到parent就是上一次提交的commit id。接下來我們再打印tree的內容看看里面保存的是什么：

獲取tree的內容后我們繼續打印對于ReadMe的信息，我們發現我們添加了以行hello git被記錄了下來，所以將來我們對于文件修改(增加、修改、刪除)的操作，通過add commit之后，都會被對象庫中的git對象記錄下來。

---

2.4、修改文件

Git比其他版本控制系統設計得優秀，因為Git跟蹤并管理的是修改，而非文件。 什么是修改？比如你新增了一行，這就是一個修改，刪除了一行，也是一個修改，更改了某些字符，也是一個修改，刪了一些又加了一些，也是一個修改，甚至創建一個新文件，也算一個修改。
下面我們給ReadMe文件添加以行hello word。
接著我們使用git status可以查看工作區的狀態：

沒有暫存區的內容可以提交，因為我們還沒有add添加到暫存區。并且可以看到我們ReadMe文件在工作區被修改了。

但是我們怎么知道新增了哪些內容呢？因為上面我們進行測試只有兩行，但是將來寫代碼可能會有成百上前行，你并不一定能記得住。所以就需要使用git diff命令查看工作區和版本庫文件的區別：
git diff [file]命令用來顯示暫存區和工作區文件的差異，顯示的格式正是Unix通用的diff格式。也可以使用git diff HEAD – [file]命令來查看版本庫和工作區文件的區別。

a/ReadMe表示修改前的ReadMe文件，b/ReadMe表示修改后的ReadMe文件。—表示修改前，+++表示修改后。-1表示修改前的第一行，+1，2表示修改后的第一行和第二行。下面顯示我們新增了hello world內容。
接著我們添加到倉庫中：

---

2.5、版本回退

之前我們也提到過，Git能夠管理文件的歷史版本，這也是版本控制器重要的能力。如果有一天你發現之前前的工作做的出現了很大的問題，需要在某個特定的歷史版本重新開始，這個時候，就需要版本回退的功能了。
執行git reset命令用于回退版本，可以指定退回某一次提交的版本。要解釋?下回退本質是要將版本庫中的內容進行回退，工作區或暫存區是否回退由命令參數決定：
git reset 命令語法格式為： git reset [–soft | --mixed | --hard] [HEAD]
? --mixed為默認選項，使用時可以不用帶該參數。該參數將暫存區的內容退回為指定提交版本內容，工作區文件保持不變。
? --soft參數對于工作區和暫存區的內容都不變，只是將版本庫回退到某個指定版本。
? --hard參數將暫存區與工作區都退回到指定版本。切記工作區有未提交的代碼時不要用這個命令，因為工作區會回滾，你沒有提交的代碼就再也找不回了，所以使用該參數前?定要慎重。

我們以之前寫的為例：

ReadMe現在有兩行，我們以git和world簡寫替代，對于工作區、暫存區、版本庫現在都是一樣的，都有git、world。現在我們需要進行版本回退，回退到ReadMe文件中只有git，如果使用了--soft選項，那么就只有版本庫進行了回退。如果使用了--mixed，暫存區和版本庫都回回退，這是默認選項。如果使用了--hard選項，那么工作區、暫存區、版本庫中就都只剩下git內容了，所以這個選項一定要慎用。

下面回退到只有hello git的時候：我們以--hard演示

如圖，成功實現了版本回退，但是如果我后悔了怎么辦，沒關系，我們可以繼續使用git reset恢復：

這是因為我們剛才打印了日志獲取到了commit id，所以可以通過這個id恢復回來。

那如果我們不知道這個id呢？Git 還提供了一個git reflog命令能補救一下，該命令用來記錄本地的每一次命令。

這個0e107bd實際上就是commit id，只不過他是完整的commit id的一部分，通過這個我們可以進行版本回退，成功恢復。但是隨著長時間的開發，過一段時間如果想回退，可能commit id已經找不到了，這時候就沒辦法回退了。
并且我們注意到Git回退版本的速度非常之快，這是因為版本回退本質上是回退版本庫的內容，實際上就是修改master。

---

2.6、撤銷修改

如果我們在我們的工作區寫了很長時間代碼，越寫越寫不下去，覺得自己寫的實在是垃圾，想恢復到上一個版本。那么這就有以下三種情況：1、未add。2、已add，未commit。3、已add、已commit。

我們給ReadMe文件添加一行：xxx code，分別演示這三種情況。

情況一：僅修改了工作區，暫存區和版本庫都未修改。這時候我們可以手動修改ReadMe文件，但是如果文件很大呢？所以需要使用git checkout -- ReadMe。

情況二：修改了工作區，并且add添加到了暫存區。這時候我們使用git reset進行回退。

情況三：我們修改了工作區，并進行了add和commit，此時我們需要保證有一個前提條件，實際上將來還有一個遠端倉庫，我們將工作區內容添加到暫存區是通過git add實現的，將暫存區內容添加到版本庫是通過git commit實現的，將版本庫內容添加到遠端倉庫是通過git push實現的。但是我們需要保證commit之后并沒有push。這時候我們使用git reset進行版本回退即可。

---

2.7、刪除文件

刪除一個文件有兩種方式。
第一種方式：刪除工作區下的某個文件，然后進行git add和git commit，因為Git管理的是文件的修改(包含增加、修改、刪除)，刪除也算是一種修改。

在上面的方式我們需要進行三步操作。使用第二種方式我們可以簡化成兩步操作。

第二種方式：使用git rm刪除文件，可以簡化成兩步。

使用git rm刪除文件，不僅會修改工作區，還會添加到暫存區中，這時候我們只需要再進行git commit即可。

---

3、Git分支管理

3.1、理解分支

假設三個月后要進行武林大會，獲勝者可以迎娶村長的女兒。所以你就開始練習，第一個月你學習了基本功，之后兩個月你就學習降龍十八掌，然后參加比賽，這是正常的時間線。而你的對手跟你的學習能力一樣，所以對手也是如此。那么為了能夠打敗你的對手，你首先練習基本功，然后釋放一個分身去學習辟邪劍法，而你則學習降龍十八掌，最后要參加比賽前進行合體，這樣你就比對手多學習了一門功法。

面再回過頭來看一下HEAD的內容：

前面我們說過HEAD指向了master，我們繼續查看master，master保存的是最近一次提交的commit id，接著我們繼續查看這個git對象信息，里面保存了parent，上一次提交的commit id。

因此就會有如上圖所示，HEAD指向master，master指向最近一次的提交，然后我們可以獲取最近一次提交信息，然后再獲取上一次的提交，所以可以不斷地向前回溯。這本質就是一條提交時間線，我們稱之為主線，所以我們把master理解為主分支。
我們也可以向上面學武一樣，創建一條分支出來，然后將來這條分支提交的信息和主分支提交的信息進行合并。
另外，HEAD不僅可以指向master分支，還可以指向其他分支，如果指向其他分支，被指向的分支就是當前正在工作的分支。

---

3.2、創建、切換、合并分支

使用git branch查看分支：

*出現在master前面，表示當前工作分支為master主分支。在創建本地倉庫的時候，git會自動給我們創建要給master主分支。

下面演示一下創建分支、切換分支、合并分支的一個過程。
首先使用git branch 分支名，創建一個分支：

然后使用git checkout 分支名，切換分支：此時*出現在了dev前面，說明當前工作分支是dev分支。

同時我們發現此時HEAD指向的就是dev分支了，打印dev的內容，我們發現存儲的是之前master分支最新的一次提交。

接著我們往ReadMe文件中添加一行內容，然后進行add和commit。

此時我們發現分支dev指向的不再是之前master最新的一次提交，而是在dev分支下剛進行的提交。**

同時我們打印最新一次提交的內容，我們發現它的上一次提交就是master中最新的那一次。

然后我們再切回master主分支，看看在主分支中是否能看到ReadMe文件被添加的內容。

切回master分支后查看ReadMe文件，我們發現并沒有新增的第三行內容。并且master分支還是指向之前主分支最新的一次提交。

接著我們將dev分支合并到master分支中，需要工作分支在master分支中進行。
使用git merge 分支名，將分支合并到master主分支中：

合并后在主分支中我們就可以看到剛才在dev分支中在ReadMe文件中添加的第三行。并且在查看master分支，此時指向了剛才在dev的提交。Fast-forward表示快進模式，直接就將master原來指向自己所在分支的最新一次提交改為了指向dev分支中的最新一次提交。

上面創建分支，切換分支進行add和commit，然后合并分支的流程圖如下：

---

3.3、刪除分支

合并完成后，dev分支對于我們來說就已經沒有用了，所以需要刪除分支，免得分支占用資源。
使用git brach -d 分支名，來刪除分支。

刪除dev分支時，當前工作分支不能是dev分支，可以是其他的任意分支。
因為創建、合并和刪除分支非常快，所以Git鼓勵你使用分支完成某個任務，合并后再刪掉分支，這和直接在master分支上工作效果是一樣的，但過程更安全。

---

3.4、合并沖突

上面分支合并的時候是沒有問題的，但是也可能出現分支合并沖突的情況。
比如我們ReadMe文件目前第三行是：add on branch dev，現在假設這個不滿足我們的需求，然后我們在dev1分支中對其進行修改為：bbb on branch dev，與此同時在master分支中也對齊修改為：ccc on branch dev。那么將來進行合并的時候，git沒辦法知道你是要保留bbb還是ccc，這時候就會出現合并沖突的問題。

首先創建分支dev1然后修改ReadMe并提交：
之前我們需要先git branch創建分支然后再git checkout切換分支，這里介紹一個方法直接創建并切換：
git checkout -b 分支名。

接著我們切回master分支，在master分支中修改ReadMe文件進行提交：

接著合并dev1分支：

顯示ReadMe文件合并沖突，自動合并失敗，需要修正沖突并重新提交結果。此時我們再打開ReadMe文件看一下：

上面的<到=之間的內容表示當前工作分支主分支最新提交的內容，=到>表示分支dev1最新提交的內容。我們可以保留bbb或ccc中的其中一個，也可以兩個都保存下來，需要我們自行修改內容然后再重新提交。

我們以保留bbb為例：

將其他內容刪除只保留bbb這一行，然后我們可以git status查看一下狀態。
接著我們進行提交：

另外git log也可以可視化的查看提交的日志信息。我們可以使用如下命令：
git log --graph --abbrev-commit

---

3.5、合并模式

上面我們合并了兩次，第一次是正常合并，是Fast-forward，第二次是合并沖突，是非Fast-froward。
下面我們再次創建分支dev2，然后給ReadMe文件添加一行：abc內容，接著進行提交，然后切回主分支進行合并。

合并成功后，我們使用：git log --graph --abbrev-commit查看提交信息：

我們發現不發生沖突的合并是Fast-forward模式，我們簡稱為ff模式，此時我們查看提交日志時，看不出來最新提交到底是merge進來的還是正常提交的。而no-ff模式下可以很明顯看到是由其他分支merge進來的。

那如果我想要no-ff這種合并方式呢。我們可以在git merge的時候帶上–no-ff選項。同時我們注意到no-ff這種方式需要創建一個新的提交節點，所以需要再帶上-m。
下面切換到dev2分支，再ReadMe文件中abc中最后加上de，然后切回master分支進行合并。

然后再次查看提交日志信息：

所以在合并分支時，加上–no-ff參數就可以用普通模式合并，合并后的歷史有分支，能看出來曾經做過合并，而fast forward合并就看不出來曾經做過合并。

---

3.6、分支管理策略

在實際開發中，我們應該按照幾個基本原則進行分支管理：
首先，master分支應該是非常穩定的，也就是僅用來發布新版本，平時不能在上面干活；所以線上環境APP、網站等的代碼都是master主分支上的代碼。
那在哪干活呢？干活都在dev分支上，也就是說dev分支是不穩定的，到某個時候，比如1.0版本發布時，再把dev分支合并到master上，在master分支發布1.0版本；
你和你的小伙伴們每個人都在dev分支上干活，每個人都有自己的分支，時不時地往dev分支上合并就可以了。

---

3.7、bug分支

假如我們現在正在dev2分支上進行開發，開發到一半，突然發現master分支上面有bug，需要解決。在Git中，每個bug都可以通過一個新的臨時分支來修復，修復后，合并分支，然后將臨時分支刪除。

首先我們先創造出環境，我們在dev2分支中ReadMe文件添加i am coding…內容：

接著我們發現主分支master有bug，這時候我們切回主分支，但是發現有問題：

我們之前在dev2分支上進行開發，修改了工作區，這時候直接切回主分支，我們發現dev2開發的代碼影響到了主分支，因此不能直接切回來。

我們重新切回dev2分支，當我們開發一半master分支出了問題，這時候我們需要使用：git stash將我們開發的代碼儲存起來。


同時發現.git目錄下的refs目錄多了一個名為stash的名字。本質上就是將我們工作區修改的內容儲存到stash中。

這時候我們就可以切回master分支了，這時候就不會影響主分支了。接下來我們需要修改bug，修改bug當然也可以直接在dev2分支上修改，不過這是我們用來進行開發的分支，所以最好的做法是另外創建一個fix_bug分支來修復bug。

我們假設ReadMe的最后一行少了一個f，我們修改后提交。
接著我們需要切回主分支，然后合并fix_bug分支，完成bug修復。(這里合并應該使用--no-ff以適應下面的圖)

修復bug成功后，我們就可以切回dev2分支繼續開發工作，開發完后進行提交。
使用git stash list可以查看我們保存了哪些修改內容：

使用git stash pop可以將之前修改的內容從stash恢復出來：

最后我們在后面加上Done表示開發工作完成，接著提交：

接下來就會有問題了，如果我們直接切回master分支，然后合并dev2分支，那么就會出現合并沖突，我們需要手動解決，而手動解決極有可能導致master代碼出錯。所以這種做法是肯定不行的，如下圖：

正確做法應該是：首先dev2合并master分支的代碼，合并后就算有問題我們也可以在dev2分支下多次修改測試，不會影響master的代碼。當我們修改測試完后，在回到master分支中合并dev2分支。如下圖：

下面我們在dev2分支中合并master分支，然后解決合并沖突：記得解決沖突后還需要提交。

最后我們回到主分支，合并dev2分支即可：

---

3.8、強制刪除分支

現在遇到一種情況，產品經理讓你開發一個新功能，所以你就創建了一個dev分支然后進行開發，過了一段時間產品經理突然又說這個功能要取消了，這時候你也只能刪除這個分支了。我們之前刪除分支都是在主分支merge其他分支之后，才把其他分支刪除的。而現在我們在dev分支開發了一部分，也有進行提交，這時候如果要刪除dev分支，由于dev分支還沒有被merge到master分支中，所以使用git branch -d是無法刪除的。如果這時候我們要刪除就需要使用git branch -D強制刪除。

下面我們就演示一下這個過程：

---

4、Git遠程操作

4.1、理解分布式版本控制系統

我們目前所說的所有內容（工作區，暫存區，版本庫等等），都是在本地！也就是在你的筆記本或者計算機上。而我們的Git其實是分布式版本控制系統！
可以簡單理解為，我們每個人的電腦上都是一個完整的版本庫，這樣你工作的時候，就不需要聯網了，因為版本庫就在你自己的電腦上。既然每個人電腦上都有一個完整的版本庫，那多個人如何協作呢？比方說你在自己電腦上改了文件A，你的同事也在他的電腦上改了文件A，這時，你們倆之間只需把各自的修改推送給對方，就可以互相看到對方的修改了。
分布式版本控制系統的安全性要高很多，因為每個人電腦里都有完整的版本庫，某一個人的電腦壞掉了不要緊，隨便從其他人那里復制一個就可以了。
在實際使用分布式版本控制系統的時候，其實很少在兩人之間的電腦上推送版本庫的修改，因為可能你們倆不在?個局域網內，兩臺電腦互相訪問不了。也可能今天你的同事病了，他的電腦壓根沒有開機。因此，分布式版本控制系統通常也有一臺充當中央服務器的電腦，但這個服務器的作用僅僅是用來方便交換大家的修改，沒有它大家也一樣干活，只是交換修改不方便而已。有了這個中央服務器的電腦，這樣就不怕本地出現什么故障了（比如運氣差，硬盤壞了，上面的所有東西全部丟失，包括git的所有內容）

實際情況往往是這樣，找一臺電腦充當服務器的角色，每天24小時開機，其他每個人都從這個服務器倉庫克隆一份到自己的電腦上，并且各自把各自的提交推送到服務器倉庫里，也從服務器倉庫中拉取別人的提交。

這個中央服務器已經有現成的了，就是github和gitee。github由于是國外的網站，訪問起來比較麻煩，后面的操作我們就用gitee來做。

---

4.2、創建遠程倉庫

我們在gitee上創建一個遠程倉庫：

可以勾選初始化倉庫，選擇你這個倉庫代碼是何種語言的，也可以添加開源許可證，也可以添加.gitnore文件這個后面會說。勾選設置模板，第一個Readme文件就是進入遠程倉庫頁面最先顯示出來的，有關遠程倉庫的介紹信息。選擇分支模型，可以選擇單分支模型和其他分支模型。

如圖，設置好后創建即可。

進入倉庫，我們最先看到的就是README文件，這個文件就是用來介紹倉庫相關內容的。

切換到管理頁面，我們選擇倉庫成員管理，可以看到倉庫有四種成員：報告者、觀察者、開發者、管理員。

我們在創建倉庫的時候還選擇了Issue模板文件和Pull Request模板文件，下面來看看這兩個是什么

點擊Issues，然后點擊創建，就可以看到如圖所示，這個實際上就是別人看你的倉庫代碼，發現你倉庫代碼有bug，那么就可以通過創建Issue來告訴倉庫成員，右邊可以選負責人、標簽、哪個分支等信息，然后左邊可以寫問題、重現步驟、報錯信息等。

在處理完bug之后，就可以對該Issue進行設置，將其狀態改為已完成。

再說Pull Request，我們之前開發創建了dev分支進行開發，開發后直接回到master分支進行合并。但是實際上并不能這樣做，萬一有bug就出問題了，所以在merge之前是需要提交一個PR：合并申請單的，管理員接收后同意才能進行合并。

進入Pull Request模塊中，然后點擊創建Pull Request，我們可以填寫從哪個源分支合并到哪個目標分支，提交給管理員。

---

4.3、克隆遠程倉庫

首先復制倉庫的HTTPS連接：

然后在Linux上使用git clone 連接，進行克隆遠程倉庫：

下面使用git remote查看遠程倉庫的名稱，使用git remote -v查看更詳細信息：

遠程倉庫的默認名稱為orgin，查看更詳細信息發現有push和fetch，表示具有推和拉取的權限。

下面介紹使用SSH進行克隆的方式，首先必須將Linux服務器上的公鑰放到gitee上，才可以克隆成功。
首先進入設置：

左邊選擇SSH公鑰：可以看到我當前是沒有配置任何公鑰的。

這時候我們直接使用SSH進行克隆會出錯：因為沒有配置公鑰

第一步：創建SSH Key。在用戶主目錄下，看看有沒有.ssh目錄，如果有，再看看這個目錄下有沒有id_rsa和id_rsa.pub這兩個文件，如果已經有了，可直接跳到下一步。如果沒有，需要創建SSH Key：

我們發現我們有.ssh文件，但是.ssh文件下并沒有上述的兩個文件，所以需要我們創建：

注意，后面的這個郵箱必須和你gitee上綁定的郵箱一致。然后一路回車即可。
此時再查看.ssh目錄就發現有上述的兩個文件了。接著將公鑰獲取出來：

將公鑰復制到gitee上進行配置：

配置成功后即可進行克隆：

---

4.4、向遠程倉庫推送

從遠程倉庫克隆后，現在我們Linux上有一個remote-gitcode目錄，這個目錄就是工作區，里面的.git就是本地倉庫。我們在工作區修改后需要git add添加到暫存區中，然后再git commit添加到master分支，再使用git push推送到遠程倉庫，這樣遠程倉庫就能看到我們的改動了。需要注意的是，推送的是本地倉庫的某個分支推送到遠程倉庫的某個分支，push是分支和分支之間的交互！

下面首先需要配置我們的本地倉庫：

我們發現已經有了name和email的配置，這是因為在前面講配置的時候我才用了全局配置，所以所有本地倉庫都生效。但是要注意，這里的name和email得和gitee上的保持一致，所以上面我修改了name。

然后創建一個file.txt，寫入內容，進行add和commit，并push到遠程倉庫：

這次我們提交后再查看倉庫的狀態，相比之前，多出來了git push的內容。
接著我們使用git push推送到遠程倉庫：

由于本地倉庫的分支和要推送的遠程倉庫的分支都是master，是一樣的，所以可以寫成git push origin master。

推送成功后再來看遠程倉庫就發現多了一個文件：

---

4.5、拉取遠程倉庫

上面是本地倉庫的代碼領先于遠程倉庫的代碼，我們使用git push推送到遠程倉庫。如果當遠程倉庫的代碼領先于本地倉庫的代碼，我們需要使用git pull將遠程倉庫的內容拉取到本地倉庫。

當你寫了hello git提交到遠程倉庫后，可能有其他人將遠程倉庫克隆，然后在本地倉庫修改后再推送到遠程倉庫，這時候遠程倉庫就領先于你的本地倉庫了。
下面我們簡單一些，直接在gitee上修改：

此時遠程倉庫是要比我們本地倉庫來的新的，所以我們要使用git pull命令拉取：

同樣的，遠程倉庫的分支master和本地倉庫的分支master是同名的，所以可以直接寫成git pull origin master。

---

4.6、忽略特殊文件

在日常開發中，我們有些文件不想或者不應該提交到遠端，比如保存了數據庫密碼的配置文件，那怎么讓Git知道呢？在Git工作區的根目錄下創建一個特殊的.gitignore文件，然后把要忽略的文件名填進去，Git就會自動忽略這些文件了。

由于我們當時沒有添加，所以手動創建一個。

我們在工作區創建了一個.gitignore文件，里面的內容如圖，第一行#開頭表示的是注釋。我們可以直接寫忽略某個文件的文件名，也可以忽略一類文件，比如*.so，忽略以.so結尾的所有文件。

下面就在工作區創建a.so進行測試：

創建a.so后我們使用git status查看工作區狀態，我們發現可以添加.gitignore，但是我們也創建a.so文件，正常來說也是要顯示的，這里之所以沒有顯示就是因為.gitignore中配置了，所以就忽略了。

下面使用git add .，將修改添加到暫存區中：

可以發現只有.gitignore被添加到了暫存區中，a.so文件被忽略了。

假設現在我創建了b.so文件，但是我就是想將該文件添加到暫存區，可以使用git add -f 文件名：

但是我們盡量不要使用這種方式，因為我們不想破壞.gitignore的規則，所以我們還有另一種方式，在.gitignore文件中配置專門不排除某個文件，下面配置不排除c.so文件：在.gitignore中添加!c.so

如圖，此時我們在工作區再創建c.so文件，再查看狀態就可以看到c.so了，此時c.so就沒有被忽略了。

當.gitignore文件很大了，某天我們創建了d.so文件，但是不知道為什么d.so文件被忽略了，這時候我們可以使用以下命令查看：
git check-ignore -v d.so

---

4.7、配置命令別名

比如我們在使用git status查看倉庫狀態的時候，我們覺得這樣寫太麻煩了，想改成git st，可以使用以下命令進行配置：

帶--global全局生效，alias.后面跟起的別名，最后面跟要起別名的命令。

再比如對于之前查看日志信息進行重命名：

---

5、標簽管理

5.1、操作標簽

加粗樣式
標簽tag，可以簡單的理解為是對某次commit的一個標識，相當于起了一個別名。例如，在項目發布某個版本的時候，針對最后一次commit起一個v1.0這樣的標簽來標識里程碑的意義。 這有什么用呢？相較于難以記住的commit id，tag很好的解決這個問題，因為tag一定要給一個讓人容易記住，且有意義的名字。當我們需要回退到某個重要版本時，直接使用標簽就能很快定位到。

使用git tag xxx添加一個標簽，使用git tag查看所有標簽：


可以看到，上面添加的標簽默認是給最新一次的提交添加的。

我們看到.git目錄下的refs目錄下新增一個目錄tags，里面有一個v1.0文件就是我們剛才添加的標簽，輸出該標簽的信息，里面保存的就是最新一次提交的commit id。

前面添加的標簽默認是給最新的一次提交添加的，如果我想給前面的提交添加的話需要在后面帶上commit id。

上述兩個添加標簽我們只是單純的添加標簽，我們還可以給標簽添加描述：

首先帶-a后面跟標簽名，再帶-m添加你的描述內容，默認給最新的一次提交打標，后面跟commit id表示要給對應的提交打標。

使用git show查看標簽的詳細信息：后面直接跟上標簽名即可

使用git tag -d刪除標簽：后面直接跟標簽名即可

---

5.2、推送標簽

我們遠程倉庫現在是沒有標簽的，需要使用git push將本地標簽推送到遠程倉庫中：


git push origin后面跟標簽名，可以將本地倉庫的標簽推送到遠程倉庫中。

另外我們還可以使用git push origin --tags推送所有本地標簽至遠程倉庫中：

如果我們要刪除標簽，可以直接在遠程倉庫中進行操作，但是這種做法不推薦。
我們可以現在本地刪除標簽，然后再推送到遠程倉庫中：

冒號左側表示本地倉庫，右邊表示遠程倉庫，我們在右邊加上標簽即可。

---

6、多人協作

6.1、完成準備工作

目標：遠程master分支下file.txt文件新增"aaa"和"bbb"。
實現：由開發者1新增aaa，開發者2新增bbb。
條件：在一個分支下協作完成。

開發者1在Linux上進行開發，開發者2在Windows上將倉庫克隆下來模擬第二個開發人員。
這個分支肯定不能是master分支，所以我們需要創建一個dev分支。我們首先在gitee上創建一個dev分支：

所以選在遠端倉庫有master和dev分支，我們Linux服務器上有一個master分支，還有一個遠程的origin/master分支。

我們可以使用git branch -r查看遠程的分支。這時候我們看不到dev分支，所以可以使用git pull拉取。

我們可以直接使用git pull拉取相信的內容。

下面我們可以使用git branch -a查看本地分支和遠程分支信息：

注意：之前使用的git push origin master，指定了遠程并且也指定了分支。當我們制定遠程倉庫或者遠程分支的時候是不需要建立接連的。當我們使用簡寫git push的時候，我們需要建立連接，這時候git才知道是從哪個分支到哪個分支的。包括pull也是如此。

對于開發者1準備工作完成，現在需要完成開發者2的準備工作。在windows下我們克隆遠端倉庫：

---

6.2、協作開發

首先完成開發者1的任務，我們肯定是不能直接切到遠程的dev分支進行開發的，因此需要在本地倉庫中創建一個dev分支：

創建一個dev分支，并在后面加上origin/dev，然后我們查看所有分支，發現成功創建了dev分支并且切換到了dev分支。哪么我們還發現多打印了一行，這是建立了dev分支和遠程origin/dev分支的連接。

可以使用git branch -vv查看建立的連接：

可以看到dev分支和遠程dev分支建立了連接，master分支也和遠程的master分支建立了連接。

此時如圖所示：

那么建立了連接的一個好處就是，當我們對dev分支進行提交需要推送或者從遠端拉取的時候，我們就可以簡寫成git push/git pull了，不需要后面再跟遠程倉庫名和分支名了。

下面完成開發者1的開發任務：

接下來對于開發者2需要先創建一個dev分支，我們演示一下后面不跟遠程分支，這樣就不會建立兩個分支的連接：

可以看到此時本地的dev分支就沒有和遠程的dev分支建立連接。

因為沒有建立連接，所以我們不能直接簡寫成git push/git pull，需要在后面加上遠程倉庫名和分支名，下面我們直接git pull拉取試試看：

可以看到直接git pull拉取，我們的file.txt文件內容是不變的。所以需要建立本地dev分支和遠程dev分支的連接。

我們使用以下命令建立連接：
git branch --set-upstream-to=origin/ dev

接著我們進行開發，在file.txt文件中加上bbb：

保存退出后進行add、commit、push：

這時候在推送的時候遠端就拒絕了，這是因為遠端現在file.txt有aaa的內容，然后我們本地file.txt有bbb內容，這時候直接推送就有沖突，但是git并不知道要保留哪份。所以需要先git pull拉取遠端修改的內容，然后在本地解決沖突的問題，再推送到遠端即可。


拉取后解決沖突，重新提交再推送。

---

6.3、將內容合并進master

此時遠端倉庫的dev分支file.txt中已經有了aaa和bbb，但是master分支還沒有，因為我們還沒將dev分支合并到master分支中，接下來我們就完成這個步驟。

有兩種方式：
1、我們通過pull request提交一個PR申請單，然后管理員進行合并操作。
2、本地master分支合并dev分支，接著把master再推送到遠程倉庫中。
我們推薦的是走PR工單這一種方式，這是需要通過審查員審核的。不過這里我們就采用本地的這種方案。
但是在master分支merge dev分支可能出現沖突，所以我們可以在dev分支中先merge master分支，有沖突在dev分支中解決，接著再讓master分支來merge dev分支。
在dev分支merge master分支的時候，我們要保證master分支是最新的。所以要先讓master進行git pull操作。

下面我們以開發人員1進行操作，由于開發人員1的file.txt只有aaa，所以需要先進行git pull，更新一下本地的dev分支：

接著要先切到master分支拉取一下，保證master是最新的：

再切回dev分支，然后合并master分支：

此時沒有沖突，所以我們可以直接切回master分支合并dev，如果有沖突解決后再合并即可：

最后我們就可以使用git push將本地分支推送到遠端：

此時開發完成，那么遠端的dev分支就沒用了，可以刪除了。

總結一下，在同一分支下進行多人協作的工作模式通常是這樣：
? 首先，可以試圖用 git push origin branch-name 推送自己的修改；
? 如果推送失敗，則因為遠程分支比你的本地更新，需要先用 git pull 試圖合并；
? 如果合并有沖突，則解決沖突，并在本地提交；
? 沒有沖突或者解決掉沖突后，再用git push origin branch-name推送就能成功！
? 功能開發完畢，將分支 merge 進 master，最后刪除分支。

---

6.4、多人協作2

目標：遠程master分支下新增funcion1和function2文件。
實現：由開發者1新增functino1，開發者2新增function2。
條件：在不同分支下協作完成。
我們讓某一個功能私有某一個分支。

這回我們不再遠程創建分支，我們讓開發者1在本地創建一個分支feature-1進行開發（不過我們推薦的是在遠程創建分支）：

這次我們沒有辦法在后面跟上遠程分支建立連接了，因為遠程倉庫并沒有對應分支。

接著我們進行開發：

最后使用git push進行推送，但是我們發現無法推送，這是因為本地的feature-1分支并沒有與遠程倉庫分支建立連接，所以無法直接使用git push推送。

建立連接有兩種方式，但是我們無法建立，因為遠程倉庫中沒有這個分支。
所以只能是git push后面跟上遠程倉庫名：

此時再查看分支就可以看到遠程多了一個feature-1分支：

接下來完成開發者2的任務，首先開發者2的本地master分支并不一定是最新的，所以需要先git pull一下。

此時再基于master分支去創建本地分支feature-2，就能保證是最新的代碼了，然后我們進行開發并提交推送：

相比于前面一種的多人協作，這種多人協作在push的時候是不會發生沖突的，因為它們是各自一個分支。

但天有不測風云，你的小伙伴突然生病了，但需求還沒開發完，需要你幫他繼續開發，于是他便把feature-2分支名告訴你了。這時你就需要在自己的機器上切換到feature-2分支幫忙繼續開發。

我們先查看分支信息，發現是看不到feature-2的，所以需要先使用git pull拉取。但由于當前是在feature-1分支，當前分支沒有和遠程倉庫的分支建立連接，所以報出需要建立連接的信息。但是我們還是把feature-2分支拉取下來了。
使用git pull有兩種場景：
1、拉取分支的內容，此時必須要建立當前分支和遠程分支的連接。
2、拉取倉庫的內容，此時不需要建立連接，使用git pull可以直接拉取下來。

拉取下來后，但是我們本地是沒有feature-2分支的，所以需要創建一個分支并與遠程的feature-2分支建立連接：

接著開發者1幫開發者2開發一部分內容，并進行提交推送到遠程倉庫：

現在開發者2病好了，開發者2需要繼續進行開發，但是這時候開發者1已經開發了一部分了，所以需要使用git pull拉取遠程倉庫的內容。

我們直接pull是失敗的，因為本地的分支沒有和遠程倉庫的分支建立連接。

所以我們先建立連接，再進行pull操作，當然不建立連接也可以，pull的時候指定要pull哪個分支即可：

此時開發者2結束最終開發內容，然后提交并推送：

現在我們需要將feature-1和feature-2分支合并到master分支中，我們采用發起pull request的方式來實現。

首先創建一個pull request。

然后進入pull request模塊，點擊我們剛才創建的PR申請單，下面可以查看代碼提交等信息，然后可以選擇已閱：

然后可以點擊代碼評審

選擇審查通過、測試通過并提交。

然后就可以合并分支了：



此時再看master分支，就可以看到function2.txt文件了。

接著還要合并feature-1分支，這時候當然可以直接再提交一個PR申請單，但是可能在合并的時候發生沖突。而如果直接合并到master，然后發生了沖突，我們需要手動解決，這時候可能解決會出更大的問題，因此不能這么做。需要先讓feature-1先合并master分支，如果出現沖突就在本地feature-1分支中解決，這樣就不會影響master。最后再讓master分支合并feature-1分支。(當然對于master合并feature-2分支的時候也是如此)

首先要進行feature-1合并master分支，但是此時master并不一定是最新的，所以需要先切到master從遠程倉庫拉取一下：

接著切回feature-1分支合并master：

此時如果沒有沖突會出現上面的頁面，我們直接退出即可。

由于此時沒有建立連接，所以直接git push失敗，我們使用長命令來實現：

接下來同feature-2，創建一個PR，然后通過合并。合并后feature-1和feature-2分支就可以刪掉了。

---

6.5、解決本地打印已被刪除分支的方法

我們此時遠程已經只剩下master分支了，但是已被刪除的分支在本地倉庫打印的時候還是存在。

我們可以使用git remove show origin查看遠程分支的情況：

然后我們可以使用git remote prune origin修剪：

---

7、企業級開發模型

7.1、企業級開發流程

我們知道，一個軟件從零開始到最終交付，大概包括以下幾個階段：規劃、編碼、構建、測試、發布、部署和維護。
最初，程序比較簡單，工作量不大，程序員一個人可以完成所有階段的工作。但隨著軟件產業的日益發展壯大，軟件的規模也在逐漸變得龐大。軟件的復雜度不斷攀升，一個人已經hold不住了，就開始出現了精細化分工。如下圖所示：

但在傳統的IT組織下，開發團隊(Dev)和運維團隊(Ops)之間訴求不同：
? 開發團隊(尤其是敏捷團隊)追求變化
? 運維團隊追求穩定
雙方往往存在利益的沖突。比如，精益和敏捷的團隊把持續交付作為目標，而運維團隊則為了線上的穩定而強調變更控制。部門墻由此建立起來，這當然不利于IT價值的最大化。
為了彌合開發和運維之間的鴻溝，需要在文化、工具和實踐方面的系列變革?DevOps正式登上舞臺。
DevOps（Development和Operations的組合詞）是?種重視軟件開發?員（Dev）和IT運維技術人員（Ops）之間溝通合作的文化、運動或慣例。透過自動化軟件交付和架構變更的流程，來使得構建、測試、發布軟件能夠更加地快捷、頻繁和可靠。在DevOps的軟件開發過程包含計劃、編碼、構建、測試、預發布、發布、運維、監控，由此可見DevOps的強大。 講了這么多，這個故事到底和我們課程的主題Git有什么關系呢？
舉一個很簡單的例子就能說明這個問題。一個軟件的迭代，在我們開發人員看來，說白了就是對代碼進行迭代，那么就需要對代碼進行管理。如何管理我們的代碼呢，那不就是 Git（分布式版本控制系統） ！所以 Git 對于我們開發人員來說其重要性就不言而喻了。

---

7.2、系統開發環境

1、開發環境：開發環境是程序猿們專門用于日常開發的服務器。為了開發調試方便，一般打開全部錯誤報告和測試?具，是最基礎的環境。
2、測試環境：一個程序在測試環境工作不正常，那么肯定不能把它發布到生產機上。該環境是開發環境到生產環境的過渡環境。
3、預發布環境：該環境是為避免因測試環境和線上環境的差異等帶來的缺陷漏測而設立的一套環境。其配置等基本和生產環境一致，目的是能讓我們發正式環境時更有把握！所以預發布環境是你的產品質量最后一道防線，因為下一步你的項目就要上線了。要注意預發布環境服務器不在線上集成服務器范圍之內，為單獨的一些機器。
4、生產環境：是指正式提供對外服務的線上環境，例如我們?前在移動端或PC端能訪問到的APP都是生產環境。
這幾個環境也可以說是系統開發的三個重要階段：開發->測試->上線。一張圖總結：

---

7.3、Git分支設計模型

master分支：
1、master為主分支，該分支為只讀且唯一分支。用于部署到正式發布環境，一般由合并release分支得到。
2、主分支作為穩定的唯一代碼庫，任何情況下不允許直接在master分支上修改代碼。
3、產品的功能全部實現后，最終在master分支對外發布，另外所有在master分支的推送應該打標簽（tag）做記錄，方便追溯。
4、master分支不可刪除。

feature分支：
1、feature分支通常為新功能或新特性開發分支，以develop分支為基礎創建feature分支。
2、命名以feature/開頭，建議的命名規則：feature/user_createtime_feature 。
3、新特性或新功能開發完成后，開發人員需合到develop分支。
4、一旦該需求發布上線，便將其刪除。

develop分支：
1、develop為開發分支，基于master分支創建的只讀且唯一分支，始終保持最新完成以及bug修復后的代碼。可部署到開發環境對應集群。
2、可根據需求大小程度確定是由feature分支合并，還是直接在上面開發（非常不建議）。

release分支：
1、release 為預發布分支，基于本次上線所有的feature分支合并到develop分支之后，基于develop分支創建。可以部署到測試或預發布集群。
2、命名以release/開頭，建議的命名規則：release/version_publishtime。
3、release分支主要用于提交給測試人員進行功能測試。發布提測階段，會以release分支代碼為基準進行提測。
4、如果在release分支測試出問題，需要回歸驗證develop分支看否存在此問題。
5、release分支屬于臨時分支，產品上線后可選刪除。

hotfix分支：
1、hotfix分支為線上bug修復分支或叫補丁分支，主要用于對線上的版本進行bug修復。當線上出現緊急問題需要馬上修復時，需要基于master分支創建hotfix分支。
2、命名以hotfix/開頭，建議的命名規則：hotfix/user_createtime_hotfix
3、當問題修復完成后，需要合并到master分支和develop分支并推送遠程。一旦修復上線，便將其刪除。

以上是企業級常用的一種Git分支設計規范：Git Flow模型。

---

7.4、企業級項目管理準備工作

我們前面講過DevOps，現在我們就需要使用DevOps，而gitee正好是有的，所以我們直接使用gitee了。
Gitee企業版免費版

我們選擇項目。然后點擊新建項目，選擇敏捷項目然后下一步。

輸入項目名稱和項目編號，點擊新建。

進入代碼模塊，選擇新建一個倉庫，填充相應信息，下方選擇分支模型。

剛開始是沒有成員的，我們可以點擊成員模塊進行添加成員。添加企業成員后就可以給項目和倉庫添加成員了。

---

7.5、企業級項目管理開發場景實操

現在我們要開發一個新功能，所以我們需要創建一個feature/xxx分支，我們進入代碼倉庫中，選擇分支管理，右上角有個新建分支，我們新建一個feature/xxxx，但是點擊新建的時候發現創建分支失敗了。這是因為倉庫中已經存在了feature分支。
這是因為之前在創建倉庫的時候我們選擇了創建五個分支模型，那么這樣就不能再創建分支了。但實際上我們期望的是master和develop分支是唯一的，剩下的三個分支我們要自己創建。因此我們刪掉倉庫重新創建：

此時我們選擇生產開發模型。

接著我們再創建分支，假設為支付功能的設計：

然后我們模擬一個開發過程，將倉庫克隆到本地，然后開發后提交并push到遠端。
首先創建一個本地分支同時與遠端的分支關聯：

接著完成開發然后提交并推送：

此時再看遠程倉庫已經多了一個我們開發的文件。

接下來我們需要將feature分支合并到develog分支：

我們進入分支管理中找到feature分支，點擊請求評審。

選擇好請求分支和目標分支，填寫相關信息，然后新建。

接著到達審查人的頁面，審查人可以查看詳情、提交記錄、文件改動等。審查過后可以點擊測試通過、評審通過。

然后點擊合并：

合并后我們回到develop分支就可以看到我們新提交的文件。那么這時候就進入部署的環節了，在gitee也有對應的功能，就是流水線，當然這個就是要付費才能玩的了。我們知道有這么一個環節即可。
開發人員部署測試完之后就交給測試人員了，測試人員要基于develop分支創建出一個release分支，要保證基于的develop分支一定是最新代碼。下面我們就創建一個release分支：

這時候就可以將release分支部署到測試環境上，然后測試人員進行測試。

測試完成后就需要將release分支合并到master分支上。所以我們繼續創建一個請求評審：同時下方我們選擇合并后刪除提交分支，將來合并后release分支就會被刪除。

接著審查人員和測試人員進行審查和測試，然后進行合并：

此時回到master分支，可以看到我們新增的file.txt文件，同時我們也看不到release分支了，接著我們可以把feature分支也刪除了。我們發現develop分支會一直保存我們最新的提交信息。

**修復測試環境Bug：在develop測試出現了Bug，建議大家直接在feature分支上進行修復。 修復后的提測上線流程與新需求加入的流程?致。 **

修改預發布環境Bug：在release測試出現了Bug，首先要回歸下develop分支是否同樣存在這個問題。 如果存在，修復流程與修復測試環境Bug流程一致。 如果不存在，這種可能性比較少，大部分是數據兼容問題，環境配置問題等。

修改正式環境Bug：在master測試出現了Bug，首先要回歸下release和develop分支是否同樣存在這個問題。如果存在，修復流程與修復測試環境Bug流程一致。 如果不存在，這種可能性也比較少，大部分是數據兼容問題，環境配置問題等。

緊急修復正式環境Bug：需求在測試環節未測試出Bug，上線運行一段時候后出現了Bug，需要緊急修復的。 有的企業面對緊急修復時，支持不進行測試環境的驗證，但還是建議驗證下預發布環境。可基于master創hotfix/xxx 分支，修復完畢后發布到master驗證，驗證完畢后，將master代碼合并到develop分支，同時刪掉hotfix/xxx分支。