?一、初始Git

提出問題：無論是在工作還是學習，我們在編寫各種文檔的時候，更改失誤，失誤后恢復到原來版本，不得不復制出一個副本。

每個版本由各自的內容，但最終只有一個報告需要被我們使用。

但在此之前的工作都需要這些不同版本的報告，難道每次都要去復制粘貼文本嗎？隨著版本數量的不斷增多，你還能記得這些版本各自都是修改了什么內容嗎？

于是有了--

版本控制器

為了能夠方便的管理這些不同版本的文件，便有了版本控制器。所謂的版本控制器，就是讓你了解到一個文件的歷史，以及他的發展過程的系統。通俗的講就是一個可以記錄工程的每一次改動和版本迭代的一個管理系統，同時也方便多人系統工作。

注意事項

還需要明確一點，所有的版本控制系統，其實只能跟蹤文本文件的改動。比如TXT文件，網頁，所有的程序代碼等等。本版控制系統可以告訴你每次的改動，比如在第某一行加入/刪除了某個單詞

而這些圖片、視頻這些二進制文件，雖然也能由版本控制系統管理，但是沒法跟蹤文件的變化，只能把二進制文件每次改動穿起來，也就是只要圖片從100KB到了120KB，但是修改了什么，版本控制器是不知道的。

二、Git的安裝

Linux-Ubuntu

sudo apt install git

Linux-Centos

sudo yum -y install git

三、Git的基本操作

創建Git的本地倉庫

倉庫是進行版本控制的一個文件目錄。要想對文件進行版本控制，就必須先創建一個倉庫出來。

命令：

git init

查看一下.git目錄的內容，后續進行介紹：

配置Git

安裝Git之后最需要做的就是設置你的用戶名稱和e_mail地址，這是非常重要的。配置命令為：

配置：
git config [--global] user.name "Your Name"   
git config [--global] user.email "email@example.com" 
刪除：
git config [--global] --unset user.name
git config [--global] --unset user.email
查看：
git config -l

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

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

• 工作區：是你要寫代碼或文件 的目錄
• 暫存區：stage/index。一般存放在.git目錄下的index文件，也把暫存區叫做索引
• 版本庫：又名倉庫。工作區里有一個隱藏的.git，它不算是工作區，它是Git的版本庫。這個版本庫里面的所有文件都可以被Git管理起來，每個文件的修改，刪除，Git都能跟蹤，以便任何時刻都可以追蹤歷史，或者在將來某個時刻可以“還原”。

• 圖中左側為?作區，右側為版本庫。Git的版本庫?存了很多東西，其中最重要的就是暫存區。
• 在創建Git版本庫時，Git會為我們?動創建?個唯?的master分?，以及指向master的?個指針叫HEAD。（分?和HEAD的概念后?再說）
• 當對?作區修改（或新增）的?件執? git add 命令時，暫存區?錄樹的?件索引會被更新。
• 當執?提交操作 git commit 時，master分?會做相應的更新，可以簡單理解為暫存區的?錄樹才會被真正寫到版本庫中。

所以：通過新建和粘貼進目錄的文件，并不能稱之為倉庫中的新增文件，而只是在工作區中新增了文件罷了。必須通過使用git add 和 git commit 命令才能將文件添加到倉庫中進行管理！！！

添加文件--場景一

在包含.git的?錄下新建?個ReadMe?件，我們可以使?git add 命令將文件添加到暫存區：

• 添加?個或多個?件到暫存區：git add [file1] [file2] ...
• 添加指定目錄到暫存區，包括子目錄 git add [dif]
• 添加當前目錄下的所有文件改動到暫存區：git add .

再使用 git commit 命令把暫存區內容添加到本地倉庫中：

• 提交暫存區全部內容到本地倉庫中:git commit -m "message"
• 提交暫存區的指定?件到倉庫區：git commit [file1] [file2] ... -m "message"

-m 選項，要更上描述本次提交的message，由用戶自己完成，這部分內容不能省略，要好好描述，是用來記錄你的提交細節，是給人看的。

把代碼直接提交到本地倉庫之后，可以使用 git log 命令來查看一下歷史提交記錄

這條命令顯示從近到遠的提交日志，并且可以看到我們commit的日志消息

如果先輸出信息太多的話，可以加上 --pretty=oneline 參數

查看.git文件

在執行 git add 之后會默認生成一個index，也就是我們的暫存區，add后的內容就是“添加”到了這里（事實上是索引被添加到了這里，內容在objects庫中）

HEAD就是我們默認指向的master分支的指針，而默認的master分支里的一連串的內容就是保存當前最新的commit id：

查找Object時要將commit id分成2部分，前2位是文件夾的名稱，后38位是文件名稱

找到這個文件之后，一般不能直接看到里面是什么，該類文件是經過sha（安全哈希算法）加密郭的文件，但是我們可以使用git cat-file命令來查看版本庫對象的內容。

小結

在本地的git倉庫中，有幾個文件或者目錄很特殊

• index：暫存區，git add后會更新這個內容
• HEAD：默認指向master分支的一個指針
• refs/heads/master：文件里保存當前的master分支的最新的commit id。
• objects：包含了創建的各種版本庫對象及其內容，可以簡單理解為放了git維護的所有的修改

添加文件--場景二

現在創建兩個文件file4和file5

touch file4 file5

把file4加入到暫存區中

git add file4

然后執行這條命令，發現只有一個文件發生了修改，而我們本意是想要同時管理file4和file5。這是因為git commit只能把暫存區中的文件加入到本地倉庫中

git commit -m "add file"[master 1a15c78] add file1 file changed, 0 insertions(+), 0 deletions(-)create mode 100644 file4

修改文件

Git比其他的版本控制系統設計得優秀，因為Git跟蹤的是修改，而非文件。

什么是修改？?如你新增了??，這就是?個修改，刪除了??，也是?個修改，更改了某些字符， 也是?個修改，刪了?些?加了?些，也是?個修改，甚?創建?個新?件，也算?個修改。

對ReadMe文件進行一次修改

cat ReadMehello git
hello world

此時倉庫中的ReadMe和我們工作區中的ReadMe是不同的，如何查看當前倉庫的狀態呢？可以使用 git status 。

可以看出，ReadMe確實被修改了，但是沒有完成添加和提交

目前，只是知道了文件被修改了，但是哪些地方被修改了呢？可以通過?git diff?命令來查看

git diff ReadMe

git diff [file] 命令用來心事暫存區和工作區文件的差異，顯示的格式是Unix通過的diff格式，也可以使用git diff HEAD [file]命令來查看版本庫和工作區文件的區別

在進行git add ReadMe之后，進行git commit之后的狀態分別為

版本回退

之前我們也提到過，Git能夠管理?件的歷史版本，這也是版本控制器重要的能?。如果有?天你發現 之前前的?作做的出現了很?的問題，需要在某個特定的歷史版本重新開始，這個時候，就需要版本 回退的功能了。

git reset命令用來回退版本，可以指定退回某一次提交的版本。回退的被指就是向版本庫中的內容進行回退，工作區或者暫存區是否回退由命令參數決定：

git reset [--soft | --mixed | --hard] [HEAD]

• --mixed為默認選項，使用時可以不同這個參數。該參數只是將暫存區的內容退回為指定提交版本內容，工作區文件保持不變
• --soft參數對于工作區和暫存區的內容都保持不變，只是將版本庫回退到某個指定的版本
• --hard參數將暫存區和共過去都回退到指定版本。切記工作區有未提交的代碼時不要用這個命令，因為工作區會回滾，沒有提交的代碼就在要找不回來，所以使用這個參數一定要慎重
• HEAD說明：
  • 可以直接寫成commit id，表示指定退回的版本
  • HEAD表示是當前版本
  • HEAD^上一版本
  • HEAD^^上上一版本
  • ......
• 可以使用~數字表示
  • HEAD~0表示當前版本
  • HEAD~1上一版本
  • HEAD~2上上一版本
  • ..

版本回退本質是這樣的

撤銷修改

看圖理解即可

刪除文件

在Git中，刪除也是一個修改操作，如果要刪除文件，直接rm刪除，只是在工作區中刪除，后續還需要再暫存區和版本庫中刪除

推薦使用 git rm 指令，將文件從暫存區和工作區中刪除，然后再commit

分支管理

理解分支

創建分支

Git支持查看和創建其他分支，這里來創建一個自己的分支dev，對應的命令為：

git branch devgit branchdev
* master

當我們創建新的分支后，Git新建了一個指針叫做dev，*表示當前的HEAD指向的分支是master分支。

切換分支的命令

git checkout dev

再master分支上，合并兩個分支的內容

git checkout master
git merge dev

刪除分支

合并完成之后，dev分支對我們來說就沒用了，就可以被刪除掉，但是如果當前正處于dev下，就不能刪除dev分支，需要切換到其他分支

命令為：

git branch -d dev

合并沖突

在實際分?合并的時候，并不是想合并就能合并成功的，有時候可能會遇到代碼沖突的問題。

這里比較簡單，就是在marge之后手動調整沖突的代碼，并且再次提交修正后的結果！！

分支管理策略

通常合并分支時，如果可能，Git會采用Fast forward模式。

在這種模式下，刪除分支后，查看分支歷史時，會丟掉分支信息，看不出來最新提交到底是merge進來的還是正常提交的。

但是在合并沖突部分，我們看到通過解決沖突問題會再進行一次新的提交，最后的狀態為

那么這就不是fast forward模式了，這樣的好處是，沖分支歷史上就可以看出是分支信息。

Git支持強制禁用fast forward模式，那么就會在merge時生成一個新的commit，這樣從分支歷史上就可以看出分支信息。?比如：

創建新的分支，對ReadMe文件進行修改，添加到暫存區，版本庫，切回master分支，開始合并兩個分支的內容

git merge dev2 --no-ff -m "merge dev2"

再使用這個命令查看一下

git log --graph --pretty=oneline --abbrev-commit*   dd30dcb (HEAD -> master) merge dev2
|\  
| * fbf25f7 (dev2) md ReadMe
|/

分支策略

在實際開發中，我們應該按照幾個基本原則進行分支管理：

首先，master分支應該是非常穩定的，也就是僅用來發布新版本，平常不能再上面干活

干活都在dev分支上，也就是說，dev分支是不穩定的，到某個時候，再把dev分支合并到master上

bug分支

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

當然我們可以直接再dev2分支上對代碼進行修改，但是這樣違背了我們創建dev2的初心，所以還是更建議再創建一個分支去單獨完成這個修改的任務。于是現在我們需要切換到master分支去新建一個分支，但是現在dev2的代碼在工作區中開發了一半，還無法提交，該怎么辦？

Git提供了git stash命令，可以將當前的工作區信息進行儲藏，被儲藏的內容可以在將來某個時間恢復出來。

git stashSaved working directory and index state WIP on dev2: 41b082f modify ReadMe

查看一下當前的狀態

git statusOn branch dev2
nothing to commit, working tree clean

這樣就可以切換到master分支去創建一個新的分支fix_bug，再切換到fix_bug分支去完成修改任務。

在fix_bug分支中完成對錯誤的修改任務之后，再次切換到master分支和fix_bug分支進行合并。合并之后，可以刪除掉fix_bug分支，然后再次切換到dev2分支進行剛才為未完成的任務。

切換到dev2分支之后，我們首先需要恢復現場，命令：

查看：git stash list刪除：git stash pop

在dev2中完成任務之后我們有兩個選擇

1. 直接在master分支合并dev2分支，但是這樣有一個問題就是，dev2和master分支是存在沖突的，玩意修改不當，可能會有更大的問題出現，所以還是更加建議第二種方法
2. 在dev2分支合并master分支，然后再切換到master分支去合并dev2分支

最后檢查一下有沒有把dev2和bug_fix分支刪除

刪除臨時分支

添加一個新功能的時候，肯定不希望因為一些代碼把主分支搞亂了，所以每次添加一個新的共呢個，最好新建一個分支，我們將其稱之為feature分支，在上面開發，完成之后，合并，最后，刪除這個分支。

可是，有時候我們在這個分支上開發了一半，可能會被叫停。這個時候我們需要把我們開發的整個新功能刪掉，這時候用傳統的git branch -d 命令刪除分支是不行的，因為沒有合并。

其實直接使用強制刪除就行了

git branch -D [分支名]

小節

分支在實際中有什么作用呢？假設你準備開發一個新的功能，但是需要兩周才能完成，第一周你寫了50%的代碼，如果立刻提交，由于代碼還有沒完成，不完整的代碼庫會影響別人。如果等代碼全部寫完再一次提交，又存在丟失每天進度的巨大風險。

所以有了分支，據不用怕了。你創建了一個屬于自己的分支，別人看不到，還繼續在原來的分支上正常工作，而你在自己的分支上工作，想提交就提交，知道開發完畢后，再一次性合并到原來的分支上，這樣既安全還不影響別人的工作。

遠程操作

理解分布式版本控制系統

目前所說的全部的內容都是在本地的，也就是在一臺主機上。但是GIt是分布式版本控制系統，這是什么意思呢？

可以簡單理解為，我們每個?的電腦上都是?個完整的版本庫，這樣你?作的時候，就不需要聯? 了，因為版本庫就在你??的電腦上。既然每個?電腦上都有?個完整的版本庫，那多個?如何協作 呢？??說你在??電腦上改了?件A，你的同事也在他的電腦上改了?件A，這時，你們倆之間只需 把各?的修改推送給對?，就可以互相看到對?的修改了。

分布式版本控制系統的安全性要高很多，因為每個人電腦里都有完整的版本庫，某一個人的電腦壞掉了不要緊，隨便從其他人那里復制一個就行了。

在實際開發中，分布式版本控制系統更普遍的是有一臺充當“中央服務器”的電腦，但這服務器的作用是方便大家交換修改，沒有他也沒有關系，只是交換不方便罷了。有了這個中央服務器的電腦，這樣就不用怕本地出現什么故障了。

遠程倉庫

GitHub訪問不方便，這里使用gitee。gitee可能有的校園網會禁止訪問，可以切換成其他網絡。

自行新建一個開源的遠程倉庫，填寫一下介紹即可。

克隆遠程倉庫

克隆/下載遠端倉庫到本地，需要使用git clone命令，后面跟上哦我們的遠端倉庫的鏈接，遠端倉庫的鏈接可以從倉庫中找到：點擊克隆/下載

SSH協議和HTTPS協議是Git最常使?的兩種數據傳輸協議。SSH協議使?了公鑰加密和公鑰登陸機 制，體現了其實?性和安全性，使?此協議需要將我們的公鑰放上服務器，由Git服務器進?管理。使 ?HTTPS?式時，沒有要求，可以直接克隆下來。

SSH協議和HTTPS協議都是Git最常用的兩種數據傳輸協議。SSH協議是以哦那個了公鑰加密和公鑰登陸機制，特體現了實用性和安全性，使用此協議需要將我們的公鑰放在服務器上，由Git服務器進行管理。使用HTTPS方式的時候，沒有要求，可以直接克隆下來。

使用HTTPS方式，直接執行下面這段代碼就行了：

git clone [HTTPS的克隆鏈接]

使用SSH方式：

git clone [SSH的克隆鏈接]

如果直接使用這個命令的話，服務器會拒絕clone鏈接，因為我們沒有設置公鑰。

• 創建SSH Key。在用戶主目錄下，看看有沒有.ssh目錄，如果有，看看這個目錄下有沒有id_rsa和id_rsa.pub這兩個文件，有的話，直接跳到下一步；沒有的話，需要創建SSH Key：

ssh-keygen -t rsa -C "gitee上綁定的郵箱地址"

順利的話，可以在??主?錄?找到 個就是SSHKey的秘鑰對， .ssh ?錄，??有 id_rsa 和 id_rsa.pub 兩個?件，這兩 id_rsa 是私鑰，不能泄露出去， id_rsa.pub 是公鑰，可以放?地告 訴任何?。?

• 添加??的公鑰到遠端倉庫。

之后再執行第一條命令就行了

向遠程倉庫推送

本地已經clone成功了遠程倉庫，我們就可以向倉庫中提交內容，例如新增一個文件。

提交時要注意，如果我們之前設置過全局的name和e-mail，這兩項配置需要和gitee上配置的?? 名和郵箱?致，否則會出錯。或者從來沒有設置過全局的name和e-mail，那么我們第?次提交時也 會報錯。這就需要我們重新配置下了，同樣要注意需要和gitee上配置的??名和郵箱?致。如何配置 已講過，在這?就不再贅述。 到這?我們已經將內容提交?本地倉庫中，如何將本地倉庫的內容推送?遠程倉庫呢，需要使? push 命令， 該命令?于將本地的分?版本上傳到遠程并合并，命令格式如下：

git push <遠程主機名> <本地分支名>:<遠程分支名># 如果本地分支名和遠程分支名相同，可以省略冒號后面的內容
git push <遠程主機名> <本地分支名>

拉取遠程倉庫

Git既然可以多人開發，那么就必然有遠程倉庫的版本新于我本地版本的情況，這時候我想要和遠程版本保持一致的話，我就需要使用拉取遠程倉庫的指令--

git pull <遠程主機名> <遠程分支名>:<本地分支名>#如果遠程分支是與當前分支合并，則冒號后面的內容可以省略。
git pull <遠程主機名> <遠程分支名>

?配置Git

忽略特殊文件

在日常開發中，往往有一些文件不想/不應該被提交到遠端，怎樣讓Git知道呢？其實再Git的工作區的根目錄下創建一個特殊的.gitignore文件，然后把要忽略的文件的名字填進去，GIt就會自動忽略這些文件了。

當初在創建倉庫時就可以為我們生成，不過需要我們勾選一個選項。

如果當初沒有勾選也沒有關系，在工作區創建一個也行。

vim .gitignore

可以在文件中寫入以下內容?

*.so
!c.so

這個意思是忽略掉所以的?.so?文件，除了?c.so

這時如果我想要添加一個b.so被管理是不行的，因為會被忽略掉。

這時候可以向c.so一樣在.gitignore配置，也可以使用（但不推薦）

git add -f b.so

隨著.gitignore中的內容增多，我們在添加某些文件的時候可以無法添加成功，不知其所以然，覺得可能是被忽略了。所以來查看一下是否是因為.gitignore。由于內容太多，直接看肯定是不方便的，所有有這樣的指令。

git check-ignore -v [file]

這樣可以找出文件被忽略的原因?

配置命令

說白了，就是起別名。

舉個例子，把git status簡化成git st

git config --global alias.st status

?標簽管理

理解標簽

標簽tag，可以簡單理解為是對某次commit的一個標識，相當于起了一個別名。例如，在項目發布某個版本的時候，針對最后一次commit起一個v1.0這樣的標簽來標識里程牌的意義。

相較于難以記憶的commit id，tag能很好的解決這個問題，因為tag一定要給人一個讓人容易記住的，有意義的名字。當我們需要回退到某個重要的版本的時候，直接使用標簽就能很快定位。

創建標簽

首先要切換到相應的分支（需要打標簽的分支）上，然后--

# 創建標簽
git tag [name]#查看所有標簽
git tag

?默認標簽是打在最新提交的commit上的。那如何在指定的commit上打標簽呢？方法是找到歷史提交的commit id，然后打上就行了。

git tag [name] [commit id]

注意，git tag的標簽不是按時間順序列出，?是按字?排序的。?

還可以通過這條命令來查看標簽信息

git show [tagname]

Git還提供可以創建帶有說明的標簽，用-a指定標簽名，-m指定說明文字，格式為：

git tag -a [name] -m "XXX" [commit id]

除此之外，打完標簽之后，.git庫中也有多出tag目錄，tag目錄下有我們創建的標簽

操作標簽

如果標簽打錯了，也可以刪除，比如說我們要刪除v1.0這個標簽，可以使用命令

git tag -d v1.0

因為創建的標簽都儲存在本地，不會自動推送到遠程。所以，打錯的標簽可以在本地安全刪除。

如果需要推送某個標簽，使用命令：
?

git push origin <tagname>

當然，如果本地有多個標簽的話，可以使用命令，一次性的全部推送到遠端

git push origin --tags

刪除碼云上的標簽

• 先在本地刪除這個標簽，比如說我們要刪除v1.0

git tag -d v1.0

• 然后把這個刪除信息推送到遠程倉庫即可

git push origin :v1.0

?多人協作

多人協作一

實現多人協作開發！

目標：在遠程master分支下的file.txt文件新增代碼"aaa"、"bbb"

實現：由開發者1新增"aaa"，由開發者2新增"bbb"

條件：在一個分支下協作實現

來分析一下，既然要在一個分支下實現，那這個分支一定不可能是master，因為之前我們就知道amster分支上的代碼一定的穩定的，所以我們需要創建一個新的分支。

可以直接在倉庫里創建一個新的分支--dev，步驟如下

master->管理->新建分支->名稱隨意-常規分支

然后開始在兩個主機上實現目標

插曲

來說明一下這個git push命令。這個命令是把本地的分支上的內容推送到遠程倉庫的某一個分支的操作。既然是從一個分支，到另一個分支，總得知道是誰給誰吧。于是，命令為

git push <遠程主機名> <本地分支名>:<遠程分支名>

這時候，有人就會問了，這么長，能不能簡化一下？答案是可以的。?

讓本地的分支追蹤遠程倉庫的分支之后，可以只使用git push命令即可完成推送任務

git branch --set-upstream-to=origin/<branch> dev#或者在創建dev分支的時候，使用這條命令
git checkout -b dev origin/dev

繼續我們兩臺主機的操作：

首先主機1下，率先修改file.txt文件，在文件中寫入aaa，并且進行add, commit, push操作

然后來操作一下主機2，對于主機2，我們按部就班的跟著主機1一樣操作。但是在push操作的時候，我們出現了問題，因為Git的dev分支并不知道應該怎么處理沖突，所以干脆直接報錯吧。

這個時候我們就需要在主機2上先使用git pull命令，把遠程的dev分支下的最新的內容拉取到本地，類似于解決合并沖突一樣，解決沖突之后，再把這個內容push到遠程倉庫中。

做到這一步，還沒有完成，因為我們只是在遠程倉庫的dev分支中完成了目標，還沒有把它合并到master分支上。

1. PR，提交一個申請單給管理員，由管理員負責
2. 采用本地的方法，master分支（需要保持最新的狀態）合并dev分支，本地master分支推送到遠程master分支
   1. 當然用master分支合并dev分支，之前我們就做過，而且為了保持master分支的穩定性，我們采用的是dev分支先來合并master分支，解決沖突，然后master分支再合并dev分支

雖然更推薦PR的方法，但是這里來描述一下本地的方法

首先，分別把master分支和dev分支更新的對應倉庫的最新狀態，本地master分支對應遠程倉庫的master分支，本地dev分支對應遠程倉庫的dev分支，說白了就是在兩個分支下執行命令——

git pull

?然后在本地切換到dev分支，執行命令——

git merge master

然后切回到master分支，執行命令——

git merge devgit push

最后把本地和遠程倉庫中沒用的分支都刪除掉。

多人協作二

目標：遠程master分支下新增function1和funciton2文件

實現：由開發者1新增funciton1，由開發者2新增funciton2

條件：在不同的分支下協作完成，各自讓每個功能私有一個分支

這個步驟應該和上邊的差不多，建議可以自己先鍛煉一下

之前我們使用的是遠程創建分支的方式，這里來介紹一下本地創建分支的方法

大致的操作就是在本地創建好分支之后，再推送到遠程。

更推薦的是遠程創建分支的方式

創建并切換feature-1分支

git checkout -b feature-1

新建function1文件，并寫入一定內容，然后add。commit。之后直接使用 git push 會失敗，因為沒有和遠程分支綁定，而且遠程也沒有與我們相對應的分支。所以我們使用命令——

git push origin feature-1

這個命令可以在遠程創建相應的分支，并推送到這個分支上，但是不會綁定遠程分支。

同理于feature-2

假如說現在負責feature-2的人臨時有事，這個function2的開發工作給了你，你該怎么處理呢？

首先，明確一下，我本地（主機一）是沒有關于feature-2分支的內容的，所以首先我需要從遠程倉庫pull

git pull有兩種功能

1. 從遠程倉庫中獲取某個分支下的內容（這個需要建立連接）
2. 獲取遠程倉庫下的分支

git pull之后可以發現多出了遠程倉庫的feature-2分支，所以在本地創建一個feature-2分支并且和遠程的分支相連接

git checkout -b feature-2 origin/feature-2 

然后進行更新即可。

最后的任務就是把feature-1和feature-2分支合并到master分支上。

--其實就是PR的操作罷了，當然在合并第二份分支的時候可以采用現在非master分支上合并再合并到master分支的方法，更加的安全。

著手刪除分支，遠程倉庫的分支可以直接再管理分支中刪除。至于本地的這些

  dev
* feature-1feature-2masterremotes/origin/HEAD -> origin/masterremotes/origin/devremotes/origin/feature-1remotes/origin/feature-2remotes/origin/master

可以使用這個命令，對分支進行修剪

git remote prune origin

完~