【Git原理與使用】-- 分支管理

這篇具有很好參考價值的文章主要介紹了【Git原理與使用】-- 分支管理。希望對大家有所幫助。如果存在錯誤或未考慮完全的地方，請大家不吝賜教，您也可以點(diǎn)擊"舉報違法"按鈕提交疑問。

理解分支

創(chuàng)建分支

查看當(dāng)前分支

創(chuàng)建本地分支

切換分支

合并分支

刪除分支

合并沖突

分支管理策略

分支策略?

bug 分支

不建議的合并方式

建議的合并方式

第一步

第二步

刪除臨時分支

理解分支

? ? ? ? 分支就是科幻電影里面的平行宇宙，當(dāng)你正在電腦前努力學(xué)習(xí) C++ 的時候，另?個你正在另?個平行宇宙里努力學(xué)習(xí) JAVA。如果兩個平行宇宙互不干擾，那對現(xiàn)在的你也沒啥影響。不過，在某個時間點(diǎn)，兩個平行宇宙合并了，結(jié)果：你既學(xué)會了 C++ 又學(xué)會了 JAVA！

git分支管理,Git,git

回顧：在講解工作區(qū)、暫存區(qū)、版本庫的概念的時候有所提到，在版本庫中是有一個HEAD指針，其是指向了一個 master 分支。?
[qcr@ecs-205826 project]$ cat .git/HEAD 
ref: refs/heads/master
[qcr@ecs-205826 project]$ cat .git/refs/heads/master 
dccd2a4405215cffcf40a12308449e27b1e58ea0
????????master里面存儲的就是我們的最新的一次提交，而最新的一次提交對應(yīng)的就是commit id，對應(yīng)的就是對象庫中的一個對象的索引，我們可以適應(yīng) log 命令進(jìn)行查看。
[qcr@ecs-205826 project]$ git log --pretty=oneline
dccd2a4405215cffcf40a12308449e27b1e58ea0 刪除test3
1bba34a04f231d8ad49f3ce5079879144cf6f4db 臨時空文件
8f2b55aca176fb578cf39952f776c3da9aa50009 新增一行
e797df72c0669a2b81339ff4854328126d2e6c8e 一行你好，用于學(xué)習(xí)git
[qcr@ecs-205826 project]$ 
????????在版本回退里，每次提交，Git都把它們串成?條時間線，這條時間線就可以理解為是一個分?。截止到目前，只有?條時間線，在Git里，這個分?叫主分?，即 master 分?。再來理解?下HEAD，HEAD 嚴(yán)格來說不是指向提交，而是指向master，master才是指向提交的，所以，HEAD 指向的就是當(dāng)前分支。

????????每次提交，master分支都會向前移動一步，這樣隨著我們不斷提交，master分支的線也越來越長，而HEAD只要?直指向master分支即可指向當(dāng)前分支。

創(chuàng)建分支

????????Git 支持持我們查看或創(chuàng)建其他分支，在這?我們來創(chuàng)建第?個自己的分支 dev ，對應(yīng)的命令為：

查看當(dāng)前分支

????????查看當(dāng)前本地所有分支?branch。

[qcr@ecs-205826 project]$ git branch
* master

? ? ? ? 其實(shí)在我們創(chuàng)建本地倉庫的時候，git會為我們自動創(chuàng)建出來一個master主分支，所以此處只有一個master分支，而前面有一個*號，就是因?yàn)閙aster前面存在一個HEAD指針。HEAD是不止可以指向master分支，還可以指向其他的任意分支的，而被HEAD指向的分支其實(shí)才是當(dāng)前的工作分支。所以master前面有一個*號，其實(shí)是因?yàn)楫?dāng)前我們正在master上工作。

創(chuàng)建本地分支

????????創(chuàng)建本地分支 dev。

[qcr@ecs-205826 project]$ git branch dev
[qcr@ecs-205826 project]$ git branch
  dev
* master

????????通過*號我們可以知道，HEAD 指針還是指向 master 分支的，可以通過查看驗(yàn)證：

[qcr@ecs-205826 project]$ cat .git/HEAD
ref: refs/heads/master

? ? ? ? 這個時候通過 tree 命令查看 .git 可以發(fā)現(xiàn)：
?

git分支管理,Git,git

? ? ? ? ?以前只有一個 master ，而這一次多了一個 dev ，通過查看 dev 內(nèi)的內(nèi)容可以發(fā)現(xiàn)：

[qcr@ecs-205826 project]$ cat .git/refs/heads/dev 
dccd2a4405215cffcf40a12308449e27b1e58ea0
[qcr@ecs-205826 project]$ cat .git/refs/heads/master
dccd2a4405215cffcf40a12308449e27b1e58ea0

? ? ? ? 其里面也是一個 commit id ，并且其里面放的內(nèi)容與 master 里面放的內(nèi)容是一摸一樣的，指向的是最新的一次提交。

git分支管理,Git,git

? ? ? ? ?原因就是因?yàn)椋何覀儎?chuàng)建 dev 分支的時候，是基于最新的一次的提交創(chuàng)建出來的，即我們在git branch dev 的時候是站在當(dāng)前最新的一個版本上去創(chuàng)建的。

切換分支

? ? ? ? 如果想在對應(yīng)的分支下進(jìn)行操作，即切換到 dev 分支下進(jìn)行開發(fā)，使用?git checkout 命令即可完成切換。

[qcr@ecs-205826 project]$ git checkout dev
Switched to branch 'dev'
[qcr@ecs-205826 project]$ git branch
* dev
  master

git分支管理,Git,git

????????我們發(fā)現(xiàn) HEAD 已經(jīng)指向了 dev，就表示我們已經(jīng)成功的切換到了 dev 上了。接下來，在 dev 分支下修改 ReadMe 文件，新增一行內(nèi)容，并進(jìn)行一次提交操作。

[qcr@ecs-205826 project]$ cat test.txt 
你好
hello
on dev branch

? ? ? ? 然后進(jìn)行提交。

[qcr@ecs-205826 project]$ git add test.txt 
[qcr@ecs-205826 project]$ git commit -m "新增一行"
[dev d9412c1] 新增一行
 1 file changed, 1 insertion(+)

????????這個時候再切回 master 分支，進(jìn)行查看我們在 dev 分支下進(jìn)行修改并提交的 test.txt 文件。

[qcr@ecs-205826 project]$ git checkout master
Switched to branch 'master'
[qcr@ecs-205826 project]$ git branch
  dev
* master
[qcr@ecs-205826 project]$ cat test.txt 
你好
hello

????????可以發(fā)現(xiàn)在 dev 上的修改并沒有在 master 上體現(xiàn)出來。并且這個時候我們再打印 dev 里面的內(nèi)容，可以發(fā)現(xiàn)發(fā)生了改變。

[qcr@ecs-205826 project]$ cat .git/refs/heads/dev 
d9412c152d40b391d55c01a75e60d99f78ef45cf

? ? ? ? 也就是說 dev 分支其實(shí)也是每一次提交，對應(yīng)進(jìn)行一次的更新的，我們可以查看此處 dev 中更新的 commit id 的 parent 是什么。

[qcr@ecs-205826 project]$ git cat-file -p d9412c152d40b391d55c01a75e60d99f78ef45cf
tree c7375ebb32b60c3e84d5b0f78b2cb6817060de54
parent dccd2a4405215cffcf40a12308449e27b1e58ea0
author qcr <2390139574@qq.com> 1688126065 +0800
committer qcr <2390139574@qq.com> 1688126065 +0800

新增一行

git分支管理,Git,git

? ? ? ? ?可以發(fā)現(xiàn)，是創(chuàng)建完 dev 分支的時候里面保存的內(nèi)容。也就是說我們在 dev 分支上，實(shí)現(xiàn)了一次的提交，實(shí)際上是進(jìn)行了：

git分支管理,Git,git

? ? ? ? 所以，當(dāng)切換到 master 分?之時，HEAD 就指向了 master，當(dāng)然看不到提交了。

合并分支

????????為了在 master 主分?上能看到新的提交，就需要將 dev 分?合并到 master 分?，合并后，master 就能看到 dev 分支提交的內(nèi)容了，首先如果是想讓 master 分支來合并 dev 分支，必須要先切到 master 分支上。

[qcr@ecs-205826 project]$ git branch
  dev
* master
[qcr@ecs-205826 project]$ git merge dev
Updating dccd2a4..d9412c1
Fast-forward
 test.txt | 1 +
 1 file changed, 1 insertion(+)

? ? ? ? 這個時候我們再查看 test.txt 文件，可以發(fā)現(xiàn) master 分支下的文件確實(shí)發(fā)生了改變。

[qcr@ecs-205826 project]$ git branch
  dev
* master
[qcr@ecs-205826 project]$ cat test.txt 
你好
hello
on dev branch

? ? ? ? 并且 master 中存的 commit id 也變?yōu)榱?dev 中的最新提交。

[qcr@ecs-205826 project]$ cat .git/refs/heads/master 
d9412c152d40b391d55c01a75e60d99f78ef45cf
[qcr@ecs-205826 project]$ cat .git/refs/heads/dev 
d9412c152d40b391d55c01a75e60d99f78ef45cf

git分支管理,Git,git

? ? ? ? 這個時候再回頭看一看在 master 分支中合并?dev 分支的命令。

git分支管理,Git,git

? ? ? ? Fast-forward 代表 “ 快進(jìn)模式 ” ，也就是直接把 master 指向 dev 的當(dāng)前提交，所以合并速度非?？?。

Note：當(dāng)然，也不是每次合并都能 Fast-forward，我們后?會講其他方式的合并。

刪除分支

????????合并完成后，dev 分支對于我們來說就沒用了，因?yàn)?dev 分支所需要達(dá)到的目標(biāo)已經(jīng)做到了，并且已經(jīng)將結(jié)果交付給了 master 主分支，那么 dev 分支就需要被刪除掉（荒廢的分支會占用一定的資源，并且不利于管理）。

Note：如果當(dāng)前正處于某分支下，就不能刪除當(dāng)前分?。
[qcr@ecs-205826 project]$ git branch
* dev
  master
[qcr@ecs-205826 project]$ git branch -d dev
error: Cannot delete the branch 'dev' which you are currently on.

[qcr@ecs-205826 project]$ git branch
  dev
* master
[qcr@ecs-205826 project]$ git branch -d dev
Deleted branch dev (was d9412c1).
[qcr@ecs-205826 project]$ git branch
* master

????????此時的狀態(tài)如圖如下所示。?

git分支管理,Git,git

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

合并沖突

????????可是，在實(shí)際分支合并的時候，并不是想合并就能合并成功的，有時候可能會遇到代碼沖突的問題。為了演示這問題，創(chuàng)建?個新的分支?dev?，并切換至目標(biāo)分支。

Note：我們可以使用?git checkout -b dev??步完成創(chuàng)建并切換的動作。

????????大致操作流程：

[qcr@ecs-205826 project]$ git checkout -b dev
Switched to a new branch 'dev'
[qcr@ecs-205826 project]$ vim test.txt 
[qcr@ecs-205826 project]$ git add test.txt 
[qcr@ecs-205826 project]$ git commit -m "最后一行添加5個a"
[dev 0bd9eb1] 最后一行添加5個a
 1 file changed, 1 insertion(+), 1 deletion(-)
[qcr@ecs-205826 project]$ git checkout master
Switched to branch 'master'
[qcr@ecs-205826 project]$ vim test.txt 
[qcr@ecs-205826 project]$ git add test.txt 
[qcr@ecs-205826 project]$ git commit -m "最后一行添加5個b"
[master 88dbe15] 最后一行添加5個b
 1 file changed, 1 insertion(+), 1 deletion(-)

? ? ? ? 于是我就得到了如下關(guān)系的兩個分支。

git分支管理,Git,git

? ? ? ? 這個時候本地的倉庫就如下圖類似：

git分支管理,Git,git

???????? 這種情況下， Git 只能試圖把各自的修改合并起來，但這種合并就可能會有沖突。

[qcr@ecs-205826 project]$ git branch
  dev
* master
[qcr@ecs-205826 project]$ git merge dev
Auto-merging test.txt
CONFLICT (content): Merge conflict in test.txt
Automatic merge failed; fix conflicts and then commit the result.

????????發(fā)現(xiàn) test.txt 文件有沖突后，可以直接查看?件內(nèi)容，要說的是 Git 會? <<<<<<<、=======、>>>>>>> 來標(biāo)記出不同分?的沖突內(nèi)容，如下所示：

[qcr@ecs-205826 project]$ cat test.txt 
你好
hello
<<<<<<< HEAD
bbbbb on dev branch
=======
aaaaa on dev branch
>>>>>>> dev

git分支管理,Git,git

????????此時我們必須要手動調(diào)整沖突代碼，并需要再次提交修正后的結(jié)果！ （再次提交很重要，切勿忘記）

? ? ? ? 我們需要自行的編寫，來決定代碼的保留。

? ? ? ? 沖突修復(fù)完整之后就是對應(yīng)的，一定需要進(jìn)行的提交的操作。?

[qcr@ecs-205826 project]$ git add .
[qcr@ecs-205826 project]$ git commit -m "使用dev分支的變動"
[master 937bd7e] 使用dev分支的變動

???????? 到這里沖突就解決完成，此時的狀態(tài)變成了如下圖所示：

git分支管理,Git,git

????????因?yàn)槲覀兙褪窃僦暗幕A(chǔ)上，進(jìn)行了又一次的提交。這個時候 master 就指向了最新的一次的提交了，但是 dev 還是執(zhí)行的它的提交。

[qcr@ecs-205826 project]$ cat .git/refs/heads/master 
937bd7e54a78557ff84d4d0ab095f635b9b30596

[qcr@ecs-205826 project]$ cat .git/refs/heads/dev 
0bd9eb10a93857eb66698c86d21571715da0477d

[qcr@ecs-205826 project]$ git log --pretty=oneline
937bd7e54a78557ff84d4d0ab095f635b9b30596 使用dev分支的變動
88dbe15a8c877e05e17a1cbc8a0904ac1510a9d5 最后一行添加5個b
0bd9eb10a93857eb66698c86d21571715da0477d 最后一行添加5個a
d9412c152d40b391d55c01a75e60d99f78ef45cf 新增一行
dccd2a4405215cffcf40a12308449e27b1e58ea0 刪除test3
1bba34a04f231d8ad49f3ce5079879144cf6f4db 臨時空文件
8f2b55aca176fb578cf39952f776c3da9aa50009 新增一行
e797df72c0669a2b81339ff4854328126d2e6c8e 一行你好，用于學(xué)習(xí)git

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

[qcr@ecs-205826 project]$ git log --graph --abbrev-commit
*   commit 937bd7e
|\  Merge: 88dbe15 0bd9eb1
| | Author: qcr <2390139574@qq.com>
| | Date:   Fri Jun 30 23:09:03 2023 +0800
| | 
| |     使用dev分支的變動
| |   
| * commit 0bd9eb1
| | Author: qcr <2390139574@qq.com>
| | Date:   Fri Jun 30 22:17:49 2023 +0800
| | 
| |     最后一行添加5個a
| |   
* | commit 88dbe15
|/  Author: qcr <2390139574@qq.com>
|   Date:   Fri Jun 30 22:18:45 2023 +0800
|   
|       最后一行添加5個b
|  
* commit d9412c1
| Author: qcr <2390139574@qq.com>
| Date:   Fri Jun 30 19:54:25 2023 +0800
| 
|     新增一行
|  
* commit dccd2a4
| Author: qcr <2390139574@qq.com>
| Date:   Sun Jun 18 20:48:38 2023 +0800
| 
:

????????可以發(fā)現(xiàn)其左側(cè)就與我們之前畫的圖一樣。

git分支管理,Git,git

? ? ? ? 覺得太雜、太亂，可以再加一個選項(xiàng)，讓其一行漂亮干凈的顯示。

[qcr@ecs-205826 project]$ git log --graph --abbrev-commit --pretty=oneline
*   937bd7e 使用dev分支的變動
|\  
| * 0bd9eb1 最后一行添加5個a
* | 88dbe15 最后一行添加5個b
|/  
* d9412c1 新增一行
* dccd2a4 刪除test3
* 1bba34a 臨時空文件
* 8f2b55a 新增一行
* e797df7 一行你好，用于學(xué)習(xí)git

????????最后，不要忘記 dev?分支使用完畢后就可以刪除了。

[qcr@ecs-205826 project]$ git branch
  dev
* master
[qcr@ecs-205826 project]$ git branch -d dev
Deleted branch dev (was 0bd9eb1).

分支管理策略

????????通常合并分支時，如果可能?Git 會采? Fast forward 模式。如果我們采用?Fast forward 模式之后，形成的合并結(jié)果如下圖。

git分支管理,Git,git

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

? ? ? ? 舉個例子： 接下來再創(chuàng)建一個分支 dev1 用于實(shí)現(xiàn)? Fast forward 模式：

[qcr@ecs-205826 project]$ git checkout -b dev1
Switched to a new branch 'dev1'
[qcr@ecs-205826 project]$ vim test.txt 
[qcr@ecs-205826 project]$ git add .
[qcr@ecs-205826 project]$ git commit -m "dev1分支下新增一行"
[dev1 93e5bb2] dev1分支下新增一行
 1 file changed, 1 insertion(+)
[qcr@ecs-205826 project]$ git checkout master
Switched to branch 'master'
[qcr@ecs-205826 project]$ git merge dev1
Updating 937bd7e..93e5bb2
Fast-forward
 test.txt | 1 +
 1 file changed, 1 insertion(+)

????????接下來再讓我們看一看 git log 下的情況（由于此處主要是看線路，所以查看簡潔版）。

[qcr@ecs-205826 project]$ git log --graph --abbrev-commit --pretty=oneline
* 93e5bb2 dev1分支下新增一行
*   937bd7e 使用dev分支的變動
|\  
| * 0bd9eb1 最后一行添加5個a
* | 88dbe15 最后一行添加5個b
|/  
* d9412c1 新增一行
* dccd2a4 刪除test3
* 1bba34a 臨時空文件
* 8f2b55a 新增一行
* e797df7 一行你好，用于學(xué)習(xí)git

git分支管理,Git,git

? ? ? ? 可以很明顯的看出來：Fast forward 模式下，刪除分支后，查看分支歷史時，會丟掉分支信息，看不出來最新提交到底是 merge 進(jìn)來的還是正常提交的。

git分支管理,Git,git

? ? ? ? 就算是詳細(xì)顯示也是一個樣，但在合并沖突部分，我們也看到通過解決沖突問題，會再進(jìn)行?次新的提交，得到的最終狀態(tài)為：

git分支管理,Git,git

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

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

???????? 舉個例子： 接下來再創(chuàng)建一個分支 dev2?用于實(shí)現(xiàn) 強(qiáng)制禁用? Fast forward 模式：

[qcr@ecs-205826 project]$ git checkout -b dev2 
Switched to a new branch 'dev2'
[qcr@ecs-205826 project]$ vim test.txt 
[qcr@ecs-205826 project]$ git add .
[qcr@ecs-205826 project]$ git commit -m "在dev2分支下新增一行"
[dev2 803a10f] 在dev2分支下新增一行
 1 file changed, 1 insertion(+)
[qcr@ecs-205826 project]$ git checkout master
Switched to branch 'master'

????????開始合并。請注意 --no-ff 參數(shù)，表示禁用 ?Fast forward 模式。禁用? Fast forward 模式后合并會創(chuàng)建?個新的 commit ，所以加上 -m 參數(shù)，把描述寫進(jìn)去。

[qcr@ecs-205826 project]$ git merge --no-ff -m "merge dev2" dev2
Merge made by the 'recursive' strategy.
 test.txt | 1 +
 1 file changed, 1 insertion(+)
[qcr@ecs-205826 project]$ cat test.txt
你好
hello
aaaaa on dev branch
ont dev1 branch
on dev2 branch

? ? ? ? 現(xiàn)在再使用 git log 查看可以發(fā)現(xiàn)：

[qcr@ecs-205826 project]$ git log --graph --abbrev-commit --pretty=oneline
*   bb787c5 merge dev2
|\  
| * 803a10f 在dev2分支下新增一行
|/  
* 93e5bb2 dev1分支下新增一行
*   937bd7e 使用dev分支的變動
|\  
| * 0bd9eb1 最后一行添加5個a
* | 88dbe15 最后一行添加5個b
|/  
* d9412c1 新增一行
* dccd2a4 刪除test3
* 1bba34a 臨時空文件
* 8f2b55a 新增一行
* e797df7 一行你好，用于學(xué)習(xí)git

git分支管理,Git,git

Note：所以在合并分支時，加上 --no-ff 參數(shù)就可以用普通模式合并，合并后的歷史有分支，能看出來曾經(jīng)做過合并，而?fast forward 合并就看不出來曾經(jīng)做過合并。

分支策略?

????????在實(shí)際開發(fā)中，我們應(yīng)該按照幾個基本原則進(jìn)行分支管理：首先，master分支應(yīng)該是非常穩(wěn)定的，也就是僅用來發(fā)布新版本，平時不能在上面干活，干活都在dev分支上，也就是說，dev分支是不穩(wěn)定的，到某個時候，比如1.0版本發(fā)布時，再把dev分支合并到master上，在master分支發(fā)布1.0版本。

git分支管理,Git,git

? ? ? ? 我們和我們的團(tuán)隊(duì)每個人都在 dev 分支上干活，每個人都有自己的分?，時不時地往dev分支上合并就可以了。所以，團(tuán)隊(duì)合作的分支看起來就像這樣：

git分支管理,Git,git

bug 分支

????????假如我們現(xiàn)在正在 dev?分支上進(jìn)行開發(fā)，開發(fā)到?半，突然發(fā)現(xiàn) master 分支上面有 bug，需要解決。在Git中，每個 bug 都可以通過?個新的臨時分?來修復(fù)，修復(fù)后，合并分?，然后將臨時分支刪除。

[qcr@ecs-205826 project]$ git checkout -b dev
Switched to a new branch 'dev'
[qcr@ecs-205826 project]$ vim test.txt 
[qcr@ecs-205826 project]$ cat test.txt 
你好
hello
aaaaa on dev branch
ont dev1 branch
on dev2 branch
I am coding ……

? ? ? ? 這個時候突然遇到了 bug ，我們就需要新建一個分支來進(jìn)行 bug 的修復(fù)，雖然 dev 分支可以用來修復(fù) bug ，但是這違背了開辟 dev 分支的初衷，其是用來開發(fā)部分的新需求的，而不是用來解決 bug 的。這個時候就需要切到 master 分支上，然后基于 master 分支進(jìn)行創(chuàng)建一個新的分支用于解決 bug。

[qcr@ecs-205826 project]$ git checkout master
M	test.txt
Switched to branch 'master'

? ? ? ? 這個時候我么可以看到，除了打印切換成功的一行提示之外，還多打印了一行。而大寫的M就代表修改（modify），這個時候再讓我們查看 master 分支上的 test.txt 會發(fā)現(xiàn)其也發(fā)生了更改（dev 的內(nèi)容跑到了 master 上了）。

[qcr@ecs-205826 project]$ git checkout master
M	test.txt
Switched to branch 'master'
[qcr@ecs-205826 project]$ cat test.txt 
你好
hello
aaaaa on dev branch
ont dev1 branch
on dev2 branch
I am coding ……

????????這個時候查看當(dāng)前狀態(tài)。

[qcr@ecs-205826 project]$ git status
# On branch master
# Changes not staged for commit:
#   (use "git add <file>..." to update what will be committed)
#   (use "git checkout -- <file>..." to discard changes in working directory)
#
#	modified:   test.txt
#
no changes added to commit (use "git add" and/or "git commit -a")

? ? ? ? 可以發(fā)現(xiàn) test.txt 文件只是再工作區(qū)中被修改了。雖然沒有對我們的倉庫進(jìn)行影響，但是我們并不想在 master 上看到 dev 上的內(nèi)容。Git 提供了 git stash 命令，可以將當(dāng)前的工作區(qū)信息進(jìn)行儲藏，被儲藏的內(nèi)容可以在將來某個時間恢復(fù)出來。

Note：首先要在其對應(yīng)的分支下。

[qcr@ecs-205826 project]$ git checkout dev
M	test.txt
Switched to branch 'dev'
[qcr@ecs-205826 project]$ git stash
Saved working directory and index state WIP on dev: 920acfc 有bug
HEAD is now at 920acfc 有bug

? ? ? ? 通過查看 .git 中對應(yīng)的文件，可以發(fā)現(xiàn)，refs 中多了一個對應(yīng)的 stash 文件。這個文件里就是臨時抱保存的工作區(qū)中的代碼數(shù)據(jù)。

git分支管理,Git,git

? ? ? ? 這個時候在查看當(dāng)前倉庫狀態(tài)，就可以發(fā)現(xiàn)工作區(qū)是干凈的。

[qcr@ecs-205826 project]$ git status
# On branch dev
nothing to commit, working directory clean
[qcr@ecs-205826 project]$ cat test.txt 
你好
hello
aaaaa on dev branch
ont dev1 branch
on dev2 branch

? ? ? ? 而 stash?里面存的其實(shí)是已經(jīng)被 Git 追蹤、管理的一些文件，而如果是 touch 一個文件，然后其只是在工作區(qū)中新建了，并沒有進(jìn)行 add、commit 操作，其是不屬于 Git?追蹤、管理的文件。這個時候就是不可以被?git stash 命令，進(jìn)行儲藏：

[qcr@ecs-205826 project]$ touch tmp.txt
[qcr@ecs-205826 project]$ git stash
No local changes to save

????????提示為：沒有一些變動需要存儲。

? ? ? ? 當(dāng)存儲起來之后，就可以發(fā)現(xiàn) test.txt 文件里面新增的內(nèi)容也就沒有了。儲藏 dev?工作區(qū)之后，由于我們要基于 master 分支修復(fù) bug，所以需要切回 master 分支，再新建臨時分支來修復(fù) bug。

[qcr@ecs-205826 project]$ git checkout -b fit_bug
Switched to a new branch 'fit_bug'
[qcr@ecs-205826 project]$ cat test.txt 
你好
hello
aaaaa on dev branch
ont dev1 branch
on dev2 branch
[qcr@ecs-205826 project]$ vim test.txt 
[qcr@ecs-205826 project]$ cat test.txt 
你好
hello
aaaaa on dev branch
aaaaa on dev1 branch
aaaaa on dev2 branch
[qcr@ecs-205826 project]$ git add . 
[qcr@ecs-205826 project]$ git commit -m "修復(fù)內(nèi)容不完整的bug"
[fit_bug 171cefc] 修復(fù)內(nèi)容不完整的bug
 1 file changed, 2 insertions(+), 2 deletions(-)

????????修復(fù)完成后，切換到 master 分支，并完成合并，最后刪除 fix_bug 分支。

[qcr@ecs-205826 project]$ git checkout master
Switched to branch 'master'
[qcr@ecs-205826 project]$ git merge --no-ff -m "merge fit_bug" fit_bug
Merge made by the 'recursive' strategy.
 test.txt | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)
[qcr@ecs-205826 project]$ git branch -d fit_bug
Deleted branch fit_bug (was 171cefc).

????????此時，bug 的修復(fù)工作已經(jīng)做完了。

[qcr@ecs-205826 project]$ cat test.txt 
你好
hello
aaaaa on dev branch
aaaaa on dev1 branch
aaaaa on dev2 branch

? ? ? ? 至此，我們還要繼續(xù)回到 dev?分支進(jìn)行開發(fā)。

[qcr@ecs-205826 project]$ git checkout dev
Switched to branch 'dev'
[qcr@ecs-205826 project]$ cat test.txt 
你好
hello
aaaaa on dev branch
ont dev1 branch
on dev2 branch

? ? ? ? 然而此時，工作區(qū)是干凈的，剛才的工作現(xiàn)場存到哪去了？需要用?git stash list 命令進(jìn)行查看。

[qcr@ecs-205826 project]$ git stash list
stash@{0}: WIP on dev: 920acfc 有bug

? ? ? ? 工作現(xiàn)場還在，Git 把 stash 內(nèi)容存在某個地方了，但是需要恢復(fù)?下，我們可以使用 ?git stash pop 命令，并且恢復(fù)的同時會把 stash 也刪了。

[qcr@ecs-205826 project]$ git stash pop
# On branch dev
# Changes not staged for commit:
#   (use "git add <file>..." to update what will be committed)
#   (use "git checkout -- <file>..." to discard changes in working directory)
#
#	modified:   test.txt
#
no changes added to commit (use "git add" and/or "git commit -a")
Dropped refs/stash@{0} (ec2f9704d78aec920b0ef53a711241e3ce3c215b)
[qcr@ecs-205826 project]$ cat test.txt 
你好
hello
aaaaa on dev branch
ont dev1 branch
on dev2 branch
I am coding ……

? ? ? ? 這個時候可以看見，工作區(qū)中原有的內(nèi)容是恢復(fù)過來了，但是原有的 "ont" bug是并未被修復(fù)的。原因就是因?yàn)?，?chuàng)建 dev 分支的時候，是基于 master 的 bug 提交所創(chuàng)建出來的，而 master 分支下的 bug 是已經(jīng)被修復(fù)了的，所以并不會影響。

????????此時，dev 中的新項(xiàng)目的開發(fā)完成了，并進(jìn)行了提交。

[qcr@ecs-205826 project]$ vim test.txt 
[qcr@ecs-205826 project]$ cat test.txt 
你好
hello
aaaaa on dev branch
ont dev1 branch
on dev2 branch
I am coding … done
[qcr@ecs-205826 project]$ git add .
[qcr@ecs-205826 project]$ git commit -m "新功能更新完成"
[dev bdea1fa] 新功能更新完成
 1 file changed, 1 insertion(+)

git分支管理,Git,git

? ? ? ? master 分支目前最新的提交，是要領(lǐng)先于新建 dev?分支時基于的 master 分支的提交的，所以在 dev?中當(dāng)然看不見修復(fù) bug 的相關(guān)代碼。

不建議的合并方式

????????我們最終目的是要讓 master 合并 dev 分支的，那么正常情況下我們切回 master 分支直接合并即可，但這樣其實(shí)是有?定風(fēng)險的。是因?yàn)樵诤喜⒎种r可能會有沖突，而代碼沖突需要我們手動解決（在 master 上解決）。我們無法保證對于沖突問題可以正確地?次性解決掉，因?yàn)樵趯?shí)際的項(xiàng)目中，代碼沖突不只?兩行那么簡單，有可能幾十上百行甚至更多，解決的過程中難免手誤出錯，導(dǎo)致錯誤的代碼被合并到 master 上。

git分支管理,Git,git

建議的合并方式

????????解決這個問題的?個好的建議就是：最好在自己的分支上合并下 master ，再讓 master 去合并 dev ，這樣做的目的是有沖突可以在本地分支解決并進(jìn)行測試，而不影響 master 。

git分支管理,Git,git

? ? ? ? 接下來就是實(shí)操。

第一步

????????首先我們需要將 dev 與 master 進(jìn)行合并。

[qcr@ecs-205826 project]$ cat test.txt 
你好
hello
aaaaa on dev branch
ont dev1 branch
on dev2 branch
I am coding … done
[qcr@ecs-205826 project]$ git branch
* dev
  master
[qcr@ecs-205826 project]$ git merge --no-ff -m "merge master" master
Auto-merging test.txt
CONFLICT (content): Merge conflict in test.txt
Automatic merge failed; fix conflicts and then commit the result.
[qcr@ecs-205826 project]$ cat test.txt 
你好
hello
aaaaa on dev branch
<<<<<<< HEAD
ont dev1 branch
on dev2 branch
I am coding … done
=======
aaaaa on dev1 branch
aaaaa on dev2 branch
>>>>>>> master

? ? ? ? 發(fā)現(xiàn)在 test.txt 中是有沖突的，但是這一次是無所謂的，因?yàn)檫@一次沖突是在本地分支上的，在本地分支上就可以隨意的修改了。

[qcr@ecs-205826 project]$ vim test.txt 
[qcr@ecs-205826 project]$ cat test.txt 
你好
hello
aaaaa on dev branch
aaaaa on dev1 branch
aaaaa on dev2 branch
I am coding … done
[qcr@ecs-205826 project]$ git add .
[qcr@ecs-205826 project]$ git commit -m "合并與master的沖突"
[dev c6eafd4] 合并與master的沖突

第二步

? ? ? ? 然后就可以切換到 master 上，進(jìn)行dev的沒有沖突的合并了。文章來源地址http://www.zghlxwxcb.cn/news/detail-751946.html

[qcr@ecs-205826 project]$ git checkout master
Switched to branch 'master'
[qcr@ecs-205826 project]$ git merge --no-ff -m "merge dev" dev
Merge made by the 'recursive' strategy.
 test.txt | 1 +
 1 file changed, 1 insertion(+)
[qcr@ecs-205826 project]$ cat test.txt 
你好
hello
aaaaa on dev branch
aaaaa on dev1 branch
aaaaa on dev2 branch
I am coding … done
[qcr@ecs-205826 project]$ git branch -d dev
Deleted branch dev (was c6eafd4).

刪除臨時分支???????

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

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

????????可是，如果我們今天正在某個 feature 分支上開發(fā)了一半，被產(chǎn)品經(jīng)理突然叫停，說是要停止新功能的開發(fā)。雖然白干了，但是這個 feature 分支還是必須就地銷毀，留著無用了。這時使用傳統(tǒng)的 git branch -d 命令刪除分支的方法是不行的。因?yàn)橹笆褂眠@個命令進(jìn)行刪除分支的時候，該分支都是已經(jīng)進(jìn)行了 merge 操作的，這樣 Git 才支持我們刪的。

? ? ? ? 如果是一個我們還未進(jìn)行 merge 操作的時候，并且還在該分支上，進(jìn)行了一定的提交操作， Git 就會保護(hù)這個分支，因?yàn)?/span> Git 認(rèn)為只要我們創(chuàng)建出來的分支就是有用的！這個時候需要使用? git branch -d 命令強(qiáng)行刪除分支。

到了這里，關(guān)于【Git原理與使用】-- 分支管理的文章就介紹完了。如果您還想了解更多內(nèi)容，請?jiān)谟疑辖撬阉鱐OY模板網(wǎng)以前的文章或繼續(xù)瀏覽下面的相關(guān)文章，希望大家以后多多支持TOY模板網(wǎng)！