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

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

2. git 詳解及實(shí)用指南之二 （遠(yuǎn)程操作）

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

1）mastr 分支

默認(rèn)情況下，mastr是一條線，git 利用 master 指向最新的提交，再用 "HEAD" 批向 "master",就能確定當(dāng)前分支以及當(dāng)前分支的提交點(diǎn)。

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

2）分支提交

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

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

3）分支提交

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

當(dāng)分支合并之后，實(shí)際上就相當(dāng)于 master 的分支的提交點(diǎn)修改為子分支的提交點(diǎn)，而后這個(gè)合并應(yīng)該在 master 分支上完成，而后 HEAD 需要修改指針，斷開 brh 分支，而指向原本的 master 分支。

4）刪除子分支

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

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

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

git branch brh

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

git branch

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

7）切換到brh分支

git checkout brh

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

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

如果想要?jiǎng)h除子分支，那么不能在當(dāng)前分支上，所以切換回了 master 分支

git checkgout master  

刪除子分支

git branch -d brh    

建立分支的同時(shí)可以自動(dòng)的切換到子分支

git checkout -b brh       

8）切換到brh分支

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

修改 hello.js

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

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

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

9）在子分支上將修改進(jìn)行提交

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

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

10）么既然分支都已經(jīng)存在了，那么現(xiàn)在為了更加清楚，將master和brh兩個(gè)分支都提交到遠(yuǎn)程服務(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分支進(jìn)行合并(在主分支上)

git merge brh

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

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

git branch -d brh

13）提交 master 分支

git push origin master

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

14）刪除遠(yuǎn)程分支

git push origin --delete brh

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

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

1）為了方便還是建立一個(gè)新的分支 —— 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ìn)行分支數(shù)據(jù)的提交，但是有人覺得這個(gè)brh分支名稱不好，應(yīng)該使用自己的姓名簡寫完成“wzy”

git branch -m brh wzy

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

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

git push origin wzy

5）在本地察看遠(yuǎn)程的分支

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

// 只察看遠(yuǎn)程的分支
git branch -r

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

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

git branch -d wzy  

此時(shí)直接提示，分支并不能夠被刪除掉，因?yàn)檫@個(gè)分支所做出的修改還沒有進(jìn)行合并。如果要想強(qiáng)制刪除此分支， 則可以使用“-D”的參數(shù)完成。

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

刪除方式一

git push origin --delete wzy

刪除方式二

git push origin :wzy

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

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

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

等于現(xiàn)在有兩個(gè)分支對(duì)同一個(gè)文件進(jìn)行了修改，那么在進(jìn)行提交的時(shí)候一定會(huì)出現(xiàn)一個(gè)沖突。因?yàn)橄到y(tǒng)不知道到底 提交那一個(gè)分支的文件。

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

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

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

git checkout -b brh

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

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

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

git commit -a -m "add static attribute"

4）切換回 master 分支

git checkout master 

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

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

6）在master分支上進(jìn)行修改的提交

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

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

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

git merge brh

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

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

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

9） 察看 Hello.js 文件

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

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

10）手工修改 Hello.js 文件

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

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

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

git commit -a -m "conflict print"

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

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

git push origin master

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

13） 察看合并的情況

git log --graph --pretty=oneline

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

14） 刪除掉 brh 分支

git branch -d brh  

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

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

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

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

git checkout -b brh

2）建立一個(gè)新的 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） 使用非快速合并的方式進(jìn)行代碼合并

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

“--no-ff”方式會(huì)帶有一個(gè)新的提交，所以需要為提交設(shè)置一個(gè)提交的注釋。

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

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

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

在各個(gè)子分支上進(jìn)行開發(fā)工作；

團(tuán)隊(duì)中的每個(gè)成員都在各個(gè)分支上工作；

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

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

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

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

git checkout -b brh

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

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

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

git add .

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

4）將工作暫存

git stash

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

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

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

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

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

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

git checkout -b dev

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

btn.onclick = function() {
   console.log("git 分支管理練習(xí)！");
   console.log("git Mast 分支修改測(cè)試！ ")
   console.log("git 分支沖突練習(xí)！")
   console.log("臨時(shí)任務(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)被解決了，被解決之后對(duì)于 dev 的分支將沒有任何的存在意義，可以直接刪除;

git branch -d dev

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

git stash list    

13）從暫存區(qū)之中進(jìn)行恢復(fù)

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

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

git stash apply
git stash drop

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

git stash pop  

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

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

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

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

使用 git diff 生成標(biāo)準(zhǔn)的 patch

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

1） 利用 git diff 生成標(biāo)準(zhǔn)的 patch

當(dāng)前的empty.js文件

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

2） 建立一個(gè)新的分支 —— cbrh

git checkout -b cbrh    

3） 修改 empty.js文件

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

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

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

git diff empth.js  

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

5） 在cbrh上進(jìn)行代碼的提交

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

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

6） 生成補(bǔ)丁文件 —— mypatch

git diff master > mypatch

7）切換回master分支

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

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

 git checkout -b patchbrh  
 

9）應(yīng)用補(bǔ)丁信息

 
git apply mypatch

此時(shí)補(bǔ)丁可以成功的使用了。

10）提交補(bǔ)丁的操作

git commit -a -m "patch apply"

11）切換回 master 分支之中進(jìn)行分支合并

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

這樣如果只是將補(bǔ)丁數(shù)據(jù)的文件發(fā)送給開發(fā)者，那么就沒有必要進(jìn)行大量代碼的傳輸，并且在創(chuàng)建補(bǔ)丁的時(shí)候也可以針對(duì)于多個(gè)文件進(jìn)行補(bǔ)丁的創(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 測(cè)試")
} 

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

 git commit -a -m "add formatch test"  
 

4）下面需要與原始代碼做一個(gè)比較，而且比較后會(huì)自動(dòng)的生成補(bǔ)丁文件

 git format-patch -M master

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

此時(shí)已經(jīng)生成了一個(gè)補(bǔ)丁文件，因?yàn)橹恍薷牧艘淮蔚膬?nèi)容。這個(gè)補(bǔ)丁文件嚴(yán)格來將就是一個(gè) email 數(shù)據(jù)，需要將此數(shù)據(jù)發(fā)送給開發(fā)者，而后開發(fā)者可以進(jìn)行補(bǔ)丁的應(yīng)用。

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

git checkout master
git checkout -b patchbrh

6） 應(yīng)用補(bǔ)丁的信息，利用“git am”完成

git am 0001-add-formatch-test.patch 

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

7） 提交應(yīng)用的更新

 git commit -a -m "method patch apply"
 

那么此時(shí)就可以成功的應(yīng)用補(bǔ)丁進(jìn)行代碼的更正。

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

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

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

一般而言，master 分支項(xiàng)目的核心分支，只要進(jìn)行代碼的克隆，那么此分支一定會(huì)被保存下來;

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

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

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

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

git checkout -b brh

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

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

3) 將此代碼進(jìn)行提交

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

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

git push origin master    
git push origin brh  

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

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

6) [二號(hào)] 察看分支信息

git branch -a

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

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

git checkout -b brh

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

 git merge origin/brh
   

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

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

10) [二號(hào)]將新的代碼進(jìn)行提交

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

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

 git push origin brh
 

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

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

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

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

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

git pull

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

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

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

13) [二號(hào)]修改 Admin.js 類文件

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

14) [二號(hào)]將以上的代碼進(jìn)行提交

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

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

git push origin brh   

16) [一號(hào)]開發(fā)者也進(jìn)行 Admin.js 文件的修改

public class Admin() {
  console.log("多人協(xié)作測(cè)試!:")
  console.log("一號(hào)也進(jìn)行修改了!")
}

17) [一號(hào)]將代碼提交

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

但是這個(gè)時(shí)候很明顯，兩個(gè)用戶一起修改了同一個(gè)文件。

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

git pull

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

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

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

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

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

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

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

你的點(diǎn)贊是我持續(xù)分享好東西的動(dòng)力，歡迎點(diǎn)贊！

一個(gè)笨笨的碼農(nóng)，我的世界只能終身學(xué)習(xí)！

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