摘要：詳解及實用指南之一本地操作詳解及實用指南之二遠程操作創建與合并分支利用分支就可以實現多人開發的偉大模式，從而提高生產效率。分支默認情況下，是一條線，利用指向最新的提交，再用批向就能確定當前分支以及當前分支的提交點。

1. git 詳解及實用指南之一 （本地操作）

2. git 詳解及實用指南之二 （遠程操作）

利用分支就可以實現多人開發的偉大模式，從而提高生產效率。在整個 GIT 之中，主分支(master)主要是作為程序 的發布使用，一般而言很少會在主分支上進行代碼的開發，都會在各自的子分支上進行。

1）mastr 分支

默認情況下，mastr是一條線，git 利用 master 指向最新的提交，再用 "HEAD" 批向 "master",就能確定當前分支以及當前分支的提交點。

以上操作屬于項目發布版本的執行順序，因為最終發布就是 master 分支。但是對于其它的開發者，不應該應該在mastr 分支上進行。所以應該建立分支，而子分支最起碼建立的時候應該是當前的 master 分支的狀態。而分支的一但創建之后， HEAD 指針就會發生變化。

2）分支提交

如果有新的提交，則 master 分支不會改變，只有 brh 分支會發生變化。

那么此時 master 分支的版本號就落后于子分支了。但是不管子分支再怎么開發，也不是最新發布版本，所有的發布版本都保存在 master 分支上，那么就必須將分支與 master 的分支進行合并。

3）分支提交

如果有新的提交，剛 master 分支不會改變，只有 bth 分支會發生改變。

當分支合并之后，實際上就相當于 master 的分支的提交點修改為子分支的提交點，而后這個合并應該在 master 分支上完成，而后 HEAD 需要修改指針，斷開 brh 分支，而指向原本的 master 分支。

4）刪除子分支

如果有新的提交，剛 master 分支不會改變，只有 brh 分支會發生改變。

分支刪除掉之后所有的內容也就都取消了。

5）創建一個分支

git branch brh

6）當分支創建完成之后可以通過如下命令進行察看

git branch

可以發現現在提示當前工作區中有兩個分支:一個是 brh 分支，另外一個是 master 分支，而現在的分支指向的 是 master 分支。

7）切換到brh分支

git checkout brh

但是很多時候我們創建分支的最終目的就是為了切換到此分支上進行開發，所以為了方便操作，在 git 之中提供了一 個更加簡單的功能。

創建并切換分支

如果想要刪除子分支，那么不能在當前分支上，所以切換回了 master 分支

git checkgout master  

刪除子分支

git branch -d brh    

建立分支的同時可以自動的切換到子分支

git checkout -b brh       

8）切換到brh分支

現在已經成功的在brh分支上了，那么下面進行代碼的修改;

修改 hello.js

btn.onclick = function() {
   console.log("git 分支管理練習！");
}

這個時候的 Hello.java 文件是屬于子分支上的，而現在也在子分支上，那么下面查詢一下子分支的狀態。

此時更新的是子分支的內容，但是主分支上的數據呢?

9）在子分支上將修改進行提交

git commit -a -m "modified hello.js file"

當子分支的數據提交之后實際上并不會去修改 master 分支的內容。這就證明了，兩個分支上的內容是彼此獨立的。

10）么既然分支都已經存在了，那么現在為了更加清楚，將master和brh兩個分支都提交到遠程服務器上(GITHUB)

git remote set-url origin https://github.com/yootk/mldn.git 
git push origin master
git push origin brh

11）最終發布的版本一定是在master分支上，所以下面需要將brh分支與master分支進行合并(在主分支上)

git merge brh

在之前講解的時候說過實際上是修改了 master 指針為 brh 分支的指針信息。所以此時的合并方式為“Fast-forward”,表示是快速合并方式，快速的合并方式并不會產生任何的 commit id。 它只是利用了合并子分支的 commit id 繼續操作。

12）此時的brh分支沒有任何的用處了，那么就可以執行刪除操作

git branch -d brh

13）提交 master 分支

git push origin master

現在在本地上已經沒有了子分支，但是在遠程服務器上依然會存在子分支。那么下面要刪除遠程分支。

14）刪除遠程分支

git push origin --delete brh

那么此時遠程分支就已經被成功的刪除掉了。

上面演示了分支的各個操作，包括使用分支、以及合并分支，同時也清楚了對于分支有兩種方式一種 是本地分支，另外一種是遠程分支，但是對于分支在 GIT 使用之中依然會有一些小小的問題，所以下面進行集中式的說明：

1）為了方便還是建立一個新的分支 —— brh

git checkout -b brh

2）在此分支上建立一些文件

public class HelloWorld() {
  console.log("Hello World");
}

    git add .
    git commit -a -m "Add Emp.java File"   

以上的代碼是在子分支(brh)上建立的。

3）此時并沒有進行分支數據的提交，但是有人覺得這個brh分支名稱不好，應該使用自己的姓名簡寫完成“wzy”

git branch -m brh wzy

現在相當于分支名稱進行了重新的命名。

4）將分支推送到遠程服務器端

git push origin wzy

5）在本地察看遠程的分支

// 察看全部的分支，包括遠程和本地的分支
git branch -a 

// 只察看遠程的分支
git branch -r

// 只察看本地分支
git branch -l

6）此時“wzt”分支上已經做出了修改，但是并沒有與master分支進行合并，因為現在所開發的功能開發到一半發現不再需要了，所以就要廢除掉所作出的修改。于是發出了刪除 wzy 分支的命令

git branch -d wzy  

此時直接提示，分支并不能夠被刪除掉，因為這個分支所做出的修改還沒有進行合并。如果要想強制刪除此分支， 則可以使用“-D”的參數完成。

可是現在在遠程服務器上依然會存在此分支，那么就必須也一起刪除掉，但是對于刪除操作，除了之前使用過的方 式之外，也可以推送一個空的分支，這樣也表示刪除。

刪除方式一

git push origin --delete wzy

刪除方式二

git push origin :wzy

分支可以很好的實現多人開發的互操作，但是有可能出現這樣種情況:

現在建立了一個新的分支 brh，并且有一位開發者在此分支上修改了 hello.js 文件。

但是這個開發者由于不小心的失誤，又將分支切換回了 master 分支上，并且在 master 分支上也對 hello.js文件進行修改。

等于現在有兩個分支對同一個文件進行了修改，那么在進行提交的時候一定會出現一個沖突。因為系統不知道到底 提交那一個分支的文件。

master 和 brh 兩個分支上都有各自的信息提交，那么此時就形成了沖突：

那么很明顯，此時有兩個提交點，那么會出現怎樣的沖突警告呢?為了更好的說明問題，下面通過代碼進行驗證:

1）建立并切換到 brh 分支上

git checkout -b brh

2）在此分支上修改hello.js文件

btn.onclick = function() {
   console.log("git 分支管理練習！");
   console.log("git 分支沖突練習！")
}

3）在brh分支上提交此文件

git commit -a -m "add static attribute"

4）切換回 master 分支

git checkout master 

5）在 master 分支上也修改 Hello.js 文件

btn.onclick = function() {
   console.log("git 分支管理練習！");
   console.log("git Mast 分支修改測試！ ")
} 

6）在master分支上進行修改的提交

git commit -a -m "add master change file"

現在在兩個分支上都存在了代碼的修改，而且很明顯，修改的是同一個文件，那么自然進行分支合并的時候是無法 合并的。

7）合并分支(此時已經存在于master分支上)

git merge brh

此時會直接提示出現了沖突。

8）察看沖突的內容

直接提示用戶，兩次修改了 Hello.java 文件。

9） 察看 Hello.js 文件

btn.onclick = function() {
   console.log("git 分支管理練習！");
<<<<<<< HEAD
   console.log("git Mast 分支修改測試！ ")
=======
   console.log("git 分支沖突練習！")
>>>>>>> brh
}

它現在把沖突的代碼進行了標記，那么現在就必須人為手工修改發生沖突的文件。

10）手工修改 Hello.js 文件

btn.onclick = function() {
   console.log("git 分支管理練習！");
   console.log("git Mast 分支修改測試！ ")
   console.log("git 分支沖突練習！")
}

現在是希望這幾個輸出的內容都同時進行保留。

11）此時已經手工解決了沖突，而后繼續進行提交

git commit -a -m "conflict print"

那么現在的沖突問題就解決了。

12）向服務器端提交信息

git push origin master

那么在實際的開發之中，一定會存在有許多的分支合并的情況，那么我怎么知道分支合并的歷史呢?

13） 察看合并的情況

git log --graph --pretty=oneline

“-graph”指的是采用繪圖的方式進行現實。

14） 刪除掉 brh 分支

git branch -d brh  

那么此時的代碼就可以回歸正常的開發模式。

在之前進行分支合并的時候使用的全部都是“Fast forward”方式完成的，而此種方式只是改變了master指針，可是 在分支的時候也可以不使用這種快合并，即:增加上一個“--no-ff”參數，這樣就表示在合并之后會自動的再生成一個新 的 commit id，從而保證合并數據的完整性。

"-no-ff": 合并后動創建一個新的 commit

1）創建一個新的分支

git checkout -b brh

2）建立一個新的 empty.js 文件

public class Empty() {
  console.log("empty file");
}

3） 提交修改

git add.
git commit -m "add empty.js file"

4） 切換回master分支

git checkout master  

5） 使用非快速合并的方式進行代碼合并

git merge --no-ff -m "no ff commit" brh   

“--no-ff”方式會帶有一個新的提交，所以需要為提交設置一個提交的注釋。

6） 察看一下提交的日志信息

 git log --graph --pretty=oneline --abbrev-commit 

master 分支應該是非常穩定的，也就是僅用來發布新的版本，不要在此分支上開發；

在各個子分支上進行開發工作；

團隊中的每個成員都在各個分支上工作；

譬如說同在你正在一個分支上進行代碼的開發，但是突然你的領導給了你一個新的任務，并且告訴你在半個小時內 完成，那么怎么辦?

難道那開發一半的分支要提交嗎?不可能的，因為對于版本控制的基本的道德方式:你不能把有問題的代碼提交上 去，你所提交的代碼一定都是正確的代碼，那么為了這樣的問題，在 GIT 中提供了一個分支暫存的機制，可以將開發一半 的分支進行保存，而后在適當的時候進行代碼的恢復。

那么下面首先創建一個基本的開發場景。

1）創建并切換到一個新的分支

git checkout -b brh

2）下面在分支上編寫empty.js 類的文件

public class Empty() {
  console.log("empty file");
  console.log("我正在開發一半中。。。。。。")
}

3）將此文件保存在暫存區之中

git add .

這個時候由于代碼還沒有開發完成，所以不能夠進行代碼的提交。但是你的老板給了你一個新的任務，那么你就不得不去停止當前的開發任務，所以就需要將當前的開發進度進行“暫存”，等日后有時間了繼續進行恢復開發。

4）將工作暫存

git stash

5）察看一下當前的工作區中的內容

此處會直接告訴用戶當前的工作區之中沒有任何的修改。

6）察看一下當前的工作區中的內容

而后現在假設要修改的代碼還處于master分支上，所以下面切換到master分支。

那么現在假設說創建一個新的分支，用于完成老板的需求，假設分支的名稱為“dev”(也有可能是一個 bug 調試)。

7）創建并切換分支

git checkout -b dev

8） 在新的分支中修改Hello.js文件

btn.onclick = function() {
   console.log("git 分支管理練習！");
   console.log("git Mast 分支修改測試！ ")
   console.log("git 分支沖突練習！")
   console.log("臨時任務 dev 上的修改")
}

9） 提交修改的操作

git commit -a -m "dev change"  

10） 提交修改的操作

合并 deve 分支，使用 no fast forward

git merge --no-ff-m "merge dev branch" dev
 

11） 那么現在突發的問題已經被解決了，被解決之后對于 dev 的分支將沒有任何的存在意義，可以直接刪除;

git branch -d dev

12） 那么需要回歸到已有的工作狀態，但是有可能會存在有許多的暫存的狀態，可以直接使用如下命令進行列出。

git stash list    

13）從暫存區之中進行恢復

暫存區恢復之后那么所暫停的操作將沒有存在的意義，但是也有人會認為它有意義，所以對于恢復有兩種形式:

形式一:先恢復，而后再手工刪除暫存

git stash apply
git stash drop

形式二:恢復的同時也將 stash 內容刪除

git stash pop  

那么下面的任務就可以像之前那樣進行代碼的提交，而后刪除掉 brh 分支:

git commit -a -m "change empty.js"
git branch -d brh 

使用暫存策略可以很方便的解決代碼突然暫停修改的操作，是非常方便。

補丁并不是針對于所有代碼的修改，只是針對于局部的修改。在很多的代碼維護之中，如果按照最早克隆的方式將 代碼整體克隆下來實際上所花費的資源是非常龐大的，但是修改的時候可能只修改很小的一部分代碼，所以在這種情況下 就希望可以將一些代碼的補丁信息發送給開發者。而發給開發者之后他需要知道那些代碼被修改了，這樣的話就可以使用 一個極低的開銷實現代碼的修改操作，而在 GIT 之中也提供了兩種簡單的補丁方案:

使用 git diff 生成標準的 patch

使用 git format-patch 聲稱 git 專用的 patch

1） 利用 git diff 生成標準的 patch

當前的empty.js文件

public class Empty() {
  console.log("empty file");
  console.log("我正在開發一半中。。。。。。")
}

2） 建立一個新的分支 —— cbrh

git checkout -b cbrh    

3） 修改 empty.js文件

public class Empty() {
  console.log("empty file");
  console.log("我正在開發一半中。。。。。。")

  console.log("補丁修改1");
  console.log("補丁修改2");
}

4） 而后察看前后代碼的不同

git diff empth.js  

此時可以發現 Emp.java 文件修改前后的對比情況。

5） 在cbrh上進行代碼的提交

git commit -a -m "add 2 line empty.js "

此時并沒有和主分支進行提交，但是代碼已經改變了，需要的是將代碼的變化提交給開發者。

6） 生成補丁文件 —— mypatch

git diff master > mypatch

7）切換回master分支

此時會自動在項目目錄中生成一個 mypat 的補丁文件信息。這個文件是可以由 git 讀懂的信息文件，那么完成之后現在需要模擬另外一個開發者，另外一個開發者假設是專門進行補丁合并的開發者。

8）創建并切換一個新的分支

 git checkout -b patchbrh  
 

9）應用補丁信息

 
git apply mypatch

此時補丁可以成功的使用了。

10）提交補丁的操作

git commit -a -m "patch apply"

11）切換回 master 分支之中進行分支合并

git checkout master
git merge --no-ff -m "Merge Patch" patchbrh

這樣如果只是將補丁數據的文件發送給開發者，那么就沒有必要進行大量代碼的傳輸，并且在創建補丁的時候也可以針對于多個文件進行補丁的創建。

1）創建并切換到cbrh分支

git branch -D cbrh
git branch -D patchbrh 
git checkout -b cbrh

2）創建并切換到cbrh分支

public class Empty() {
  console.log("empty file");
  console.log("git format-patch 測試")
} 

3）創建并切換到cbrh分支

 git commit -a -m "add formatch test"  
 

4）下面需要與原始代碼做一個比較，而且比較后會自動的生成補丁文件

 git format-patch -M master

現在表示要與 master 分支進行比較(而-M 參數就是指定分支)。

此時已經生成了一個補丁文件，因為只修改了一次的內容。這個補丁文件嚴格來將就是一個 email 數據，需要將此數據發送給開發者，而后開發者可以進行補丁的應用。

5）創建并切換到patchbrh分支上

git checkout master
git checkout -b patchbrh

6） 應用補丁的信息，利用“git am”完成

git am 0001-add-formatch-test.patch 

現在是將發送過來的，帶有 email 格式的補丁文件進行了應用。

7） 提交應用的更新

 git commit -a -m "method patch apply"
 

那么此時就可以成功的應用補丁進行代碼的更正。

使用git diff生成補丁兼容性是比較好的，如果你是在不是git管理的倉庫上，此類方式生成的補丁是非常容易接受的;

但是如果你是向公共的開發社區進行代碼的補丁更正，那么建議使用git format-patch，這樣不僅標準，而且也可以將更正人的信息進行公布。

分支的處理實際上是為了更好的多人開發做出的準備，那么下面就將利用兩個命令行方式(模擬其他的開發者)進行項目代碼的編寫。首先說明一下:

一般而言，master 分支項目的核心分支，只要進行代碼的克隆，那么此分支一定會被保存下來;

開發者往往會建立一系列的分支，譬如，本次練習建立了一個 brh 的分支進行代碼的編寫;

如果要進行調試可以建立一個 bug 分支;

如果要增加某些新的功能則可以建立 feature 分支。

1） 創建并切換到一個新的分支:brh

git checkout -b brh

2) 在新的分支上建立一個新的文件 —— Dept.js

public class Dept() {
  console.log("多人協作開發!");
}

3) 將此代碼進行提交

git commit -a -m "add dept.js files"

4) 將兩個分支提交到服務器上去

git push origin master    
git push origin brh  

5） [二號]為了模擬第二個開發者，所以建立一個新的命令行窗口，并且將代碼復制下來(d:proclone)

git clone https://github.com/qq449245884/HelloGitHub.git

6) [二號] 察看分支信息

git branch -a

發現現在只是將 master 分支拷貝下來了，但是 brh 分支并沒有存在。

7) [二號]建立并切換到brh分支上

git checkout -b brh

8) [二號]將遠程服務器端上的brh分支的內容拷貝到本地的brh分支上

 git merge origin/brh
   

9) [二號]現在開發者增加了一個Admin.js文件

public class Admin() {
  console.log("多人協作測試!:")
} 

10) [二號]將新的代碼進行提交

git add .
git commit -m "add admin.js files"   

11) [二號]現在本地的 brh 分支代碼發生了變化，那么應該將此變化提交到遠程的 brh 分支上

 git push origin brh
 

現在代碼已經發送到了服務器上了，并且在 brh 分支上增加了新的 Admin.java 文件。

12) [一號]這個時候最原始的開發者目錄下還只是上一次提交的內容。那么需要取得最新的數據才可以

對于取得最新的分支數據有兩種方式:

git fetch: 此操作只是取得最新的分支數據，但是不會發生 merge 合并操作

git pull: 此操作取出最新分支數據，并且同時發生 merge 合并操作

git pull

實際上錯誤信息也很簡單，指的是，當前的 brh 分支和服務器上的分支沒有關系，所以如果要想讀取代碼，必須讓兩 個分支產生關聯關系。

git branch --set-upstream-to=origin/brh

隨后再次讀取所有的代碼。

13) [二號]修改 Admin.js 類文件

public class Admin() {
  console.log("多人協作測試!:")
  console.log("二號我來個性了！");
}

14) [二號]將以上的代碼進行提交

 git commit -a -m "update admin.js file"
 
 

15) [二號]向服務器端提交代碼的修改

git push origin brh   

16) [一號]開發者也進行 Admin.js 文件的修改

public class Admin() {
  console.log("多人協作測試!:")
  console.log("一號也進行修改了!")
}

17) [一號]將代碼提交

git commit -a -m "1 update admin.js file"

但是這個時候很明顯，兩個用戶一起修改了同一個文件。

18) [一號]抓取最新的更新數據

git pull

現在可以發現，此時的程序，是兩位開發者修改了同一個代碼，所以產生了沖突。同時一號開發者之中的 Admin.js 文件的內容已經變更為如下情:

public class Admin() {
  console.log("多人協作測試!:")
<<<<<<< HEAD
  console.log("一號也進行修改了!")
=======
  console.log("二號我來個性了！");
>>>>>>> a600e113d2d139efc73eee2052ad509fa95d16e3
}

19) [一號]手工解決沖突文件內容

public class Admin() {
  console.log("多人協作測試!:")
  console.log("一號也進行修改了!")
  console.log("二號我來個性了！");
}

20) 再次執行提交和服務器推送

 git commit -a -m "3 Update Admin.js File" 
 git push origin brh

現在已經成功的由本地的沖突擴充到了遠程的沖突，相信通過一系列的代碼大家也可以更好的理解分支的操作問題。

你的點贊是我持續分享好東西的動力，歡迎點贊！

一個笨笨的碼農，我的世界只能終身學習！

更多內容請關注公眾號《大遷世界》！