柚子快報(bào)邀請(qǐng)碼778899分享：【Git原理與使用】分支管理

http://yzkb.51969.com/

分支管理

1.理解分支2.創(chuàng)建分支2.1創(chuàng)建分支2.2切換分支2.3合并分支

3.刪除分支4.合并沖突4.分支管理策略5.分支策略6.bug分支7.刪除臨時(shí)分支8.小結(jié)

點(diǎn)贊??收藏??關(guān)注?? 你的支持是對(duì)我最大的鼓勵(lì)，我們一起努力吧!??

1.理解分支

Git 的殺手級(jí)功能之一（注意是之一，也就是后面還有之二，之三……）：分支。

先從小一個(gè)小故事理解分支。 比如你出生一個(gè)在武俠村，這個(gè)武俠村現(xiàn)在要召開一個(gè)武林大會(huì)，凡是贏得人可以贏取村長(zhǎng)女兒?，F(xiàn)在距離無論武林大會(huì)還有三個(gè)月的時(shí)間。第一個(gè)月你先練基本功，第二個(gè)月和第三個(gè)月學(xué)習(xí)降龍十八掌，然后到時(shí)間參加比較。你可以做這些事情你的對(duì)手也可以做這些事情。如果你們學(xué)習(xí)能力差不多，天賦差不多，比賽你倆就五五開了。但是你有一個(gè)先天優(yōu)勢(shì)，你會(huì)分身術(shù)。在練習(xí)完基本功之后你創(chuàng)造了一個(gè)分身，這個(gè)分身去學(xué)習(xí)辟邪劍法，最后在比賽之前你讓自己本體和分身進(jìn)行一個(gè)合體，合體之后你就同時(shí)掌握了兩門功法，所以參加比賽后你就把對(duì)手打得落花流水，最后贏得比賽之后贏取村長(zhǎng)女兒。

其實(shí)Git也可以做到這一套，它也可以分身，也可以合體。

在之前說的版本庫(kù)中有一個(gè)HEAD指針，它默認(rèn)指向master分支。master里面其實(shí)存儲(chǔ)的就是最近一個(gè)提交。

因此我們也可以串一條提交時(shí)間線出來，這個(gè)提交時(shí)間線我們可以稱為主線，這主線就是 master主分支。

我們也可以在主分支上創(chuàng)建一個(gè)分支，然后合并分支。

2.創(chuàng)建分支

查看本地倉(cāng)庫(kù)的分支：

git branch

創(chuàng)建本地倉(cāng)庫(kù)的時(shí)候Git就會(huì)為我們自動(dòng)創(chuàng)建master主分支

master 前面的 *，之前我們只知道HEAD指向master有這一個(gè)東西存在，但是對(duì)于HEAD指針我們并不了解它有什么功能。首先要明確HEAD不僅可以指向master分支，它也可以指向其他分支，被HEAD指向的分支就是當(dāng)前正在工作的分支。

這里我們就知道為什么 * 在master前面，因?yàn)槲覀儺?dāng)前在master分支下工作。

2.1創(chuàng)建分支

git branch [分支名]

可以看到當(dāng)前除了master分支，還有dev分支，當(dāng)前HEAD還是指向master

并且我們可以看到，剛創(chuàng)建出來的dev分支和master主分支存放的最新提交的commit id是一樣的。

我們創(chuàng)建新的分支是站在當(dāng)前最新版本上創(chuàng)建的分支，所以dev分支指向了最新的提交

那如何切換到dev分支工作呢？ 就是把HEAD指向dev，讓dev成為當(dāng)前工作的分支。

2.2切換分支

git checkout [分支名]

接下來我們就可以在dev分支進(jìn)行工作了，我們進(jìn)行一次提交

然后我們?cè)谇谢豰aster分支，然后打印ReadMe文件，發(fā)現(xiàn)新增的代碼不見了。

我們?cè)谇谢豥ev分支，發(fā)現(xiàn)這一行代碼還在

我們查看到dev分支目前最新提交的commit id，打印一下發(fā)現(xiàn)它前一個(gè)commit id正好是我們剛創(chuàng)建dev里面的conmit id也是master最新提交的commit id。這是因?yàn)槲覀冊(cè)谶@個(gè)提交線上又進(jìn)行了一次提交。dev指向了最新的一次提交，而master沒動(dòng)。

那我們想在master分支下看到這一行代碼怎么做呢？那就要將master分支和dev分支進(jìn)行一次合并操作。

2.3合并分支

如果我們想要master分支合并dev分支，我們必須要先切到master分支，然后在合并。

git merge [分支名]

Fast-forward表示快進(jìn)模式，下面在解釋。然后還打印初ReadMe改變，一行插入。 現(xiàn)在打印ReadMe就可以在master分支上看到新增的一行代碼。

合并后master分支和dev分支一樣指向最新提交的commit id

Fast-forward快進(jìn)模式，表示直接把master指向dev最新提交的commit id。所有看到合并是非?？斓?。

3.刪除分支

目前我們已經(jīng)成功創(chuàng)建了屬于自己的本地分支并且完成了自己的工作，那么對(duì)于dev分支來說它的工作已經(jīng)完成了，那dev分支就沒有用了，我們?nèi)绾螌⑺鼊h除呢？

但是要注意的是我們只能在其他的分支上才能刪除你要?jiǎng)h除的分支！

git branch -d [分支名]

因?yàn)閯?chuàng)建、合并和刪除分支非?？?，所以Git鼓勵(lì)你使用分只完成某個(gè)任務(wù)，合并后再刪掉分支，這和直接在master分支上工作效果是一樣的，但過程更安全。

4.合并沖突

在實(shí)際分支合并的時(shí)候，并不是想合并就能合并成功的，有時(shí)候可能會(huì)遇到代碼沖突的問題。

比如說dev1分支和master分支都對(duì)當(dāng)前ReadMe文件的一行代碼進(jìn)行了修改，此時(shí)就有合并沖突的問題。Git并不知道此時(shí)需要保留bbb還是ccc的代碼，這都是開發(fā)人員自己寫的是由開發(fā)人員自己決定的，所以就有合并沖突的問題。

這里我們?cè)趯W(xué)一個(gè)命令，直接一條命令完成 ，創(chuàng)建 + 切換分支

git checkout -b [分支]

創(chuàng)建dev1分支，修改ReadMe文件aaa變成bbb，然后提交

切換到master分支，也去修改ReadMe文件aaa變成ccc，然后提交

下面是此時(shí)的倉(cāng)庫(kù)狀態(tài)

然后我們讓master合并dev分支，就會(huì)發(fā)生沖突。

合并ReadMe文件沖突，我們需要手動(dòng)解決沖突然后將結(jié)果在進(jìn)行提交。

進(jìn)入ReadMe文件發(fā)現(xiàn) <<<<< Head ====== >>>>> dev1，< 到 = 之間的代碼是由當(dāng)前master分支上的代碼，= 到 > 是dev1分支上的代碼。在 < 到 > 是沖突代碼，表示bbb和ccc沖突了。Git沒辦法幫我們解決沖突，需要我們手動(dòng)解決沖突，到底是保留bbb還是ccc，還是都保留，還是都刪除，這都是由開發(fā)人員自己判斷。

比如我們現(xiàn)在保留bbb代碼，只需要把< 到 > 其他代碼刪掉即可?，F(xiàn)在就不沖突了。然后將結(jié)果重新提交。

合并沖突之后，需要手動(dòng)調(diào)整沖突代碼，并需要再次提交修正后的結(jié)果?。。ㄔ俅翁峤缓苤匾?，切勿忘記）

用帶參數(shù)的 git log也可以看到分支的合并情況

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

4.分支管理策略

到目前為止，我們已經(jīng)使用過兩次merge操作，一次是直接合并沒有發(fā)生沖突，一次合并發(fā)生沖突解決沖突后在重新提交。 對(duì)于這兩次merge操作其實(shí)分別對(duì)應(yīng)了Git提供給我們兩個(gè)merge模式。

通常合并分支時(shí)，如果可能，Git 會(huì)采用 Fast forward 模式。

可以清楚看到使用Fast - forward 快進(jìn)模式 ，在這種 Fast forward 模式下，刪除分支后，查看分支歷史時(shí)，會(huì)丟掉分支信息，看不出來最新提交到底是 merge 進(jìn)來的還是正常提交的。

但在合并沖突部分，我們也看到通過解決沖突問題，會(huì)再進(jìn)行一次新的提交，得到的最終狀態(tài)為：

那么這就不是 Fast forward 模式了，這樣的好處是，從分支歷史上就可以看出分支信息。例如我們現(xiàn)在已經(jīng)刪除了在合并沖突部分創(chuàng)建的 dev1 分支，但依舊能看到 master 其實(shí)是由其他分支合并得到：

Git 支持我們強(qiáng)制禁用 Fast forward 模式，那么就會(huì)在 merge 時(shí)生成?個(gè)新的 commit ，這樣，從分支歷史上就可以看出分?信息。

git merge --no-ff -m "xxxx" [分支]

可以看到，不使用 Fast forward 模式，merge后就像下面這樣，所以在合并分支時(shí)，加上 --no-ff 參數(shù)就可以用普通模式合并，合并后的歷史有分支，能看出來曾 經(jīng)做過合并，而 fast forward 合并就看不出來曾經(jīng)做過合并。

合并我們建議不要使用Fast-forward，而使用no-ff。

5.分支策略

在實(shí)際開發(fā)中，我們應(yīng)該按照幾個(gè)基本原則進(jìn)行分支管理：

首先，master分支應(yīng)該是非常穩(wěn)定的，也就是僅用來發(fā)布新版本，平時(shí)不能在上面干活；

那在哪干活呢？干活都在dev分支上，也就是說，dev分支是不穩(wěn)定的，到某個(gè)時(shí)候，比如1.0版本發(fā)布時(shí)，再把dev分支合并到master上，在master分支發(fā)布1.0版本；

你和你的小伙伴們每個(gè)人都在dev分支上干活，每個(gè)人都有自己的分支，時(shí)不時(shí)地往dev分支上合并就可以了。

所以，團(tuán)隊(duì)合作的分支看起來就像這樣：

6.bug分支

假如我們現(xiàn)在正在 dev2 分支上進(jìn)行開發(fā)，開發(fā)到一半，突然發(fā)現(xiàn) master 分支上面有 bug，需要解決。注意不能在master主分支上進(jìn)行代碼修復(fù)，我們需要在本地創(chuàng)建一個(gè)專門修復(fù)master主分支上的bug，修復(fù)后，合并分支，然后將臨時(shí)分支刪除。如果在master主分支上進(jìn)行代碼修復(fù)，可能會(huì)造成一個(gè)更大的bug。

可現(xiàn)在 dev2 的代碼在工作區(qū)中開發(fā)了一半，還無法提交，怎么辦？

Git 提供了 git stash 命令，可以將當(dāng)前的工作區(qū)信息進(jìn)行儲(chǔ)藏，被儲(chǔ)藏的內(nèi)容可以在將來某個(gè)時(shí)間恢復(fù)出來。

git stash

stash在refs下，注意stash里面存的是已經(jīng)被Git追蹤管理的文件，ReadMe已經(jīng)被追蹤管理了，所以對(duì)工作區(qū)ReadMe文件修改它是可以保存起來的。

接下來我們創(chuàng)建一個(gè)bug分支，對(duì)master出現(xiàn)的bug進(jìn)行修復(fù)。

比如說ReadMe文件123后面少跟了456導(dǎo)致bug，現(xiàn)在我們加上，bug修完之后進(jìn)行提交合并。

修復(fù)完bug之后，由于我們還在dev2下進(jìn)行開發(fā)，所以還要在進(jìn)行開發(fā)。但是發(fā)現(xiàn)開發(fā)的內(nèi)容不見了，原因是因?yàn)樾迯?fù)bug之前把dev2開發(fā)的內(nèi)容存儲(chǔ)到stash里面了。

我們要重新開發(fā)，就要把存到stash里面的內(nèi)容恢復(fù)過來。我們可以使用 git stash pop 命令，恢復(fù)的同時(shí)會(huì)把 stash 也刪了。

git stash pop

不過恢復(fù)之前我們還可以查看一下stash里面存了那些東西

git stash list

目前我們看到確實(shí)是恢復(fù)過來了。但是123后面并沒有跟456，也就是dev2這里并沒有修復(fù)bug，原因是因?yàn)槲覀冊(cè)趧?chuàng)建dev2的時(shí)候是基于master的有bug的時(shí)候，所以dev2還是未修復(fù)bug的狀態(tài)。不過它并不影響master主分支。

我們看此時(shí)倉(cāng)庫(kù)的狀態(tài)就能明白剛才說的這一點(diǎn)，master 分支前最新的提交，是要領(lǐng)先于新建 dev2 時(shí)基于的 master 分支的提交的，所以我們?cè)?dev2 中當(dāng)然看不見修復(fù) bug 的相關(guān)代碼。

當(dāng)dev2繼續(xù)開發(fā)完成后，就可以在dev2分支上提交了

我們的最終目的是要讓 master 合并 dev2 分支的，那么正常情況下我們切回 master 分支直接合并即可，但這樣其實(shí)是有一定風(fēng)險(xiǎn)的。

是因?yàn)樵诤喜⒎种r(shí)可能會(huì)有沖突，而代碼沖突需要我們手動(dòng)解決（在 master 上解決）。我們無法保證對(duì)于沖突問題可以正確地一次性解決掉，因?yàn)樵趯?shí)際的項(xiàng)目中，代碼沖突不只一兩行那么簡(jiǎn)單，有可能幾十上百行，甚至更多，解決的過程中難免手誤出錯(cuò)，導(dǎo)致錯(cuò)誤的代碼被合并到 master 上。此時(shí)的狀態(tài)為：

解決這個(gè)問題的一個(gè)好的建議就是：最好在自己的分支上合并下 master ，再讓 master 去合并dev ，這樣做的目的是有沖突可以在本地分支解決并進(jìn)行測(cè)試，而不影響 master 。此時(shí)的狀態(tài)為：

一般我們讓master合并自己的代碼之前，都建議這樣做。

7.刪除臨時(shí)分支

軟件開發(fā)中，總有無窮無盡的新的功能要不斷添加進(jìn)來。

添加一個(gè)新功能時(shí)，你肯定不希望因?yàn)橐恍?shí)驗(yàn)性質(zhì)的代碼，把主分支搞亂了，所以，每添加一個(gè)新功能，最好新建一個(gè)分支，我們可以將其稱之為 feature 分支，在上面開發(fā)，完成后，合并，最后，刪除該 feature 分支。

可是，如果我們今天正在某個(gè) feature 分支上開發(fā)了一半，被產(chǎn)品經(jīng)理突然叫停，說是要停止新功能的開發(fā)。雖然白干了，但是這個(gè) feature 分支還是必須就地銷毀，留著無用了。這時(shí)使用傳統(tǒng)的 git branch -d 命令刪除分支的方法是不行的，因?yàn)樗贿m用于刪除已經(jīng)merge過的分支。對(duì)于沒有merge過的分支要使用git branch -D 去刪除。

git branch -D [分支]

8.小結(jié)

分支在實(shí)際中有什么?呢？假設(shè)你準(zhǔn)備開發(fā)一個(gè)新功能，但是需要兩周才能完成，第一周你寫了50%的代碼，如果立刻提交，由于代碼還沒寫完，不完整的代碼庫(kù)會(huì)導(dǎo)致別人不能干活了。如果等代碼全部寫完再一次提交，又存在丟失每天進(jìn)度的巨大風(fēng)險(xiǎn)。

現(xiàn)在有了分支，就不用怕了。你創(chuàng)建了?個(gè)屬于你自己的分支，別人看不到，還繼續(xù)在原來的分支上正常工作，而你在自己的分支上干活，想提交就提交，直到開發(fā)完畢后，再一次性合并到原來的分支上，這樣，既安全，又不影響別人工作。

并且 Git 無論創(chuàng)建、切換和刪除分支，Git在1秒鐘之內(nèi)就能完成！無論你的版本庫(kù)是1個(gè)文件還是1萬個(gè)文件。

柚子快報(bào)邀請(qǐng)碼778899分享：【Git原理與使用】分支管理

http://yzkb.51969.com/

相關(guān)鏈接