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

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

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

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

1）mastr 分支

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

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

2）分支提交

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

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

3）分支提交

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

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

4）刪除子分支

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

分支刪除掉之后所有的內(nèi)容也就都取消了。

5）創(chuàng)建一個分支

git branch brh

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

git branch

可以發(fā)現(xiàn)現(xiàn)在提示當前工作區(qū)中有兩個分支:一個是 brh 分支，另外一個是 master 分支，而現(xiàn)在的分支指向的 是 master 分支。

7）切換到brh分支

git checkout brh

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

創(chuàng)建并切換分支

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

git checkgout master  

刪除子分支

git branch -d brh    

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

git checkout -b brh       

8）切換到brh分支

現(xiàn)在已經(jīng)成功的在brh分支上了，那么下面進行代碼的修改;

修改 hello.js

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

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

此時更新的是子分支的內(nèi)容，但是主分支上的數(shù)據(jù)呢?

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

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

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

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

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

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

git merge brh

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

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

git branch -d brh

13）提交 master 分支

git push origin master

現(xiàn)在在本地上已經(jīng)沒有了子分支，但是在遠程服務(wù)器上依然會存在子分支。那么下面要刪除遠程分支。

14）刪除遠程分支

git push origin --delete brh

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

上面演示了分支的各個操作，包括使用分支、以及合并分支，同時也清楚了對于分支有兩種方式一種 是本地分支，另外一種是遠程分支，但是對于分支在 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）此時并沒有進行分支數(shù)據(jù)的提交，但是有人覺得這個brh分支名稱不好，應該使用自己的姓名簡寫完成“wzy”

git branch -m brh wzy

現(xiàn)在相當于分支名稱進行了重新的命名。

4）將分支推送到遠程服務(wù)器端

git push origin wzy

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

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

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

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

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

git branch -d wzy  

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

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

刪除方式一

git push origin --delete wzy

刪除方式二

git push origin :wzy

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

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

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

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

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

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

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"

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

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

git merge brh

此時會直接提示出現(xiàn)了沖突。

8）察看沖突的內(nèi)容

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

9） 察看 Hello.js 文件

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

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

10）手工修改 Hello.js 文件

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

現(xiàn)在是希望這幾個輸出的內(nèi)容都同時進行保留。

11）此時已經(jīng)手工解決了沖突，而后繼續(xù)進行提交

git commit -a -m "conflict print"

那么現(xiàn)在的沖突問題就解決了。

12）向服務(wù)器端提交信息

git push origin master

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

13） 察看合并的情況

git log --graph --pretty=oneline

“-graph”指的是采用繪圖的方式進行現(xiàn)實。

14） 刪除掉 brh 分支

git branch -d brh  

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

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

"-no-ff": 合并后動創(chuàng)建一個新的 commit

1）創(chuàng)建一個新的分支

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”方式會帶有一個新的提交，所以需要為提交設(shè)置一個提交的注釋。

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

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

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

在各個子分支上進行開發(fā)工作；

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

譬如說同在你正在一個分支上進行代碼的開發(fā)，但是突然你的領(lǐng)導給了你一個新的任務(wù)，并且告訴你在半個小時內(nèi) 完成，那么怎么辦?

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

那么下面首先創(chuàng)建一個基本的開發(fā)場景。

1）創(chuàng)建并切換到一個新的分支

git checkout -b brh

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

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

3）將此文件保存在暫存區(qū)之中

git add .

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

4）將工作暫存

git stash

5）察看一下當前的工作區(qū)中的內(nèi)容

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

6）察看一下當前的工作區(qū)中的內(nèi)容

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

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

7）創(chuàng)建并切換分支

git checkout -b dev

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

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

9） 提交修改的操作

git commit -a -m "dev change"  

10） 提交修改的操作

合并 deve 分支，使用 no fast forward

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

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

git branch -d dev

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

git stash list    

13）從暫存區(qū)之中進行恢復

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

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

git stash apply
git stash drop

形式二:恢復的同時也將 stash 內(nèi)容刪除

git stash pop  

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

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

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

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

使用 git diff 生成標準的 patch

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

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

當前的empty.js文件

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

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

git checkout -b cbrh    

3） 修改 empty.js文件

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

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

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

git diff empth.js  

此時可以發(fā)現(xiàn) Emp.java 文件修改前后的對比情況。

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

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

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

6） 生成補丁文件 —— mypatch

git diff master > mypatch

7）切換回master分支

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

8）創(chuàng)建并切換一個新的分支

 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

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

1）創(chuàng)建并切換到cbrh分支

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

2）創(chuàng)建并切換到cbrh分支

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

3）創(chuàng)建并切換到cbrh分支

 git commit -a -m "add formatch test"  
 

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

 git format-patch -M master

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

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

5）創(chuàng)建并切換到patchbrh分支上

git checkout master
git checkout -b patchbrh

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

git am 0001-add-formatch-test.patch 

現(xiàn)在是將發(fā)送過來的，帶有 email 格式的補丁文件進行了應用。

7） 提交應用的更新

 git commit -a -m "method patch apply"
 

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

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

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

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

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

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

如果要進行調(diào)試可以建立一個 bug 分支;

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

1） 創(chuàng)建并切換到一個新的分支:brh

git checkout -b brh

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

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

3) 將此代碼進行提交

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

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

git push origin master    
git push origin brh  

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

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

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

git branch -a

發(fā)現(xiàn)現(xiàn)在只是將 master 分支拷貝下來了，但是 brh 分支并沒有存在。

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

git checkout -b brh

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

 git merge origin/brh
   

9) [二號]現(xiàn)在開發(fā)者增加了一個Admin.js文件

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

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

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

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

 git push origin brh
 

現(xiàn)在代碼已經(jīng)發(fā)送到了服務(wù)器上了，并且在 brh 分支上增加了新的 Admin.java 文件。

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

對于取得最新的分支數(shù)據(jù)有兩種方式:

git fetch: 此操作只是取得最新的分支數(shù)據(jù)，但是不會發(fā)生 merge 合并操作

git pull: 此操作取出最新分支數(shù)據(jù)，并且同時發(fā)生 merge 合并操作

git pull

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

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

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

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

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

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

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

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

git push origin brh   

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

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

17) [一號]將代碼提交

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

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

18) [一號]抓取最新的更新數(shù)據(jù)

git pull

現(xiàn)在可以發(fā)現(xiàn)，此時的程序，是兩位開發(fā)者修改了同一個代碼，所以產(chǎn)生了沖突。同時一號開發(fā)者之中的 Admin.js 文件的內(nèi)容已經(jīng)變更為如下情:

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

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

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

20) 再次執(zhí)行提交和服務(wù)器推送

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

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

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

一個笨笨的碼農(nóng)，我的世界只能終身學習！

更多內(nèi)容請關(guān)注公眾號《大遷世界》！