上篇文章已經(jīng)說(shuō)了Git簡(jiǎn)史以及Git基礎(chǔ)生真，那么這篇文章簡(jiǎn)單總結(jié)下Git分支
Git分支
為了理解 Git 分支的實(shí)現(xiàn)方式,我們需要回顧一下,
Git保存的不是文件差異或者變化量萝衩，而只是一系列文件快照.
- Git分支
| 分支其實(shí)就是從某個(gè)提交對(duì)象往回看的歷史 | 文字描述 |
|---|---|
 image
|
Git中的分支葡兑，本質(zhì)上就是個(gè)指向master對(duì)象的可變指針，master為默認(rèn)分支立膛，每次提交都會(huì)向前移動(dòng) |
| 多個(gè)分支指向提交數(shù)據(jù)的歷史 | 文字描述 |
|---|---|
 image
|
Git創(chuàng)建一個(gè)新分支指針從而創(chuàng)建分支揪罕，創(chuàng)建testing命令git branch testing |
| HEAD 指向當(dāng)前所在的分支 | 文字描述 |
|---|---|
 image
|
Git因?yàn)楸４嬉粋€(gè)名為HEAD的指針，它指向正在工作中本地分支指針 git branch僅是創(chuàng)建新分支宝泵，但不會(huì)自動(dòng)切換分支中去（如圖還在master上） |
| HEAD 在你轉(zhuǎn)換分支時(shí)指向新的分支 | 文字描述 |
|---|---|
 image
|
運(yùn)行g(shù)it checkout testingHEAD就指向testing分支了 |
| 每次提交后 HEAD 隨著分支一起向前移動(dòng) | 文字描述 |
|---|---|
 image
|
左圖是又提交一次的結(jié)果好啰，每次提交后HEAD隨著分支一起向前移動(dòng) 但master仍指向原來(lái)git checkout時(shí)所在的commit對(duì)象。再次執(zhí)行g(shù)it checkout masterHEAD才會(huì)指向master |
- Git—merge
| 分支的合并 — merge #1 | 文字描述 |
|---|---|
 image
|
1. #53是第一滴修補(bǔ)問題的分支 git chackout -b iss53 === git branch iss53+git checkout iss53 2.假如接到緊急任務(wù)儿奶，這時(shí)候就不必花費(fèi)大力氣來(lái)復(fù)原這些修改框往，執(zhí)行g(shù)it checkout master創(chuàng)建緊急修補(bǔ)分支git checkout -b hotfix 3.hotfix分支是從master分支所在點(diǎn)分化出來(lái)的 |
 image
|
1.測(cè)試成功后回到master把它合并起來(lái)，然后發(fā)布服務(wù)器闯捎，命令為git checkout master git merge hotfix 合并會(huì)出現(xiàn)“Fast forward”的提示 2.因?yàn)?/strong>是master并入hotfix的直接上游椰弊，只需master指針右移動(dòng)（順著走）稱為快進(jìn) 3.合并之后，master 分支和 hotfix 分支指向同一位置 |
| 分支的合并 — merge #2 | 文字描述 |
|---|---|
 image
|
1.現(xiàn)在回來(lái)處理iss53瓤鼻，完成后合并回master,不同于hotfix,開發(fā)歷史從早的地方開始分叉的 2.master->c4秉版，git額外處理為找到共同祖先C2簡(jiǎn)單三方合并 |
 image
|
三方合并后的結(jié)果重新快照，并自動(dòng)創(chuàng)建指向它的提交對(duì)象C6,可以看到C6有兩個(gè)祖先 (git自動(dòng)創(chuàng)建了一個(gè)包含了合并結(jié)果的提交對(duì)象茬祷，自己裁決哪個(gè)共同祖先才是最佳合并基礎(chǔ)清焕，這和 CVS及Subversion（1.5 以后的版本不同) |
- Git—rebase
| 分支的合并 — rebase #1 | 文字描述 |
|---|---|
 image
|
把一個(gè)分支中的修改整合到另一個(gè)分支的辦法有兩種：merge 和 rebase（衍合） 如左圖：分叉到兩個(gè)不同分支，又各自提交了更新 |
 image
|
除了merge兩個(gè)分支最新的公共祖先三方合并 另外就是C3的變化補(bǔ)丁在C4中重新打一遍->衍合 有了衍合可以把分支中提交的變化移到另一個(gè)分支重放一遍 （原理：回到共同祖先祭犯，根據(jù)當(dāng)前分支（ex··）提交的對(duì)象C3,生成補(bǔ)丁然后以master最后提交的C4為新的出發(fā)點(diǎn)秸妥，逐個(gè)應(yīng)用之前準(zhǔn)備好的補(bǔ)丁文件，最后會(huì)生成一個(gè)新的合并提交對(duì)象（C3'）沃粗，master成直接下游） |
 image
|
回到master進(jìn)行快進(jìn)合并 |
| 分支的合并 — rebase #2 | 文字描述 |
|---|---|
 image
|
從一個(gè)特性分支里再分出一個(gè)特性分支的歷史 服務(wù)器端代碼添加功能創(chuàng)建server提C3C4->從C3增加client分支并提C8C9->回server提C10 |
 image
|
將特性分支上的另一個(gè)特性分支衍合到其他分支 一次軟件發(fā)布中筛峭，我們決定先把客戶端的修改并到主線中，而暫緩并入服務(wù)端軟件的修改 git rebase --onto master server client 取出 client 分支陪每，找出 client 分支和 server 分支的共同祖先之后的變化影晓，然后把它們?cè)?master 上重演一遍 |
 image
|
快進(jìn) master 分支，使之包含 client 分支的變化 git checkout master git merge client |
 image
|
在 master 分支上衍合 server 分支 git rebase [主分支] [特性分支] 命令會(huì)先取出特性分支 server檩禾，然后在主分支 master 上重演 git rebase master server |
 image
|
最終的提交歷史 快進(jìn)主干分支 master git checkout master && git merge server |
現(xiàn)在 client 和 server 分支的變化都已經(jīng)集成到主干分支來(lái)了挂签，可以刪掉它們了
git branch -d client
git branch -d server
- Git—rebase風(fēng)險(xiǎn)
| 分支的合并 — rebase的風(fēng)險(xiǎn) | 文字描述 |
|---|---|
| 把衍合當(dāng)成一種在推送之前清理提交歷史的手段，而且僅僅衍合那些尚未公開的提交對(duì)象盼产，就沒問題饵婆。 | 如果衍合那些已經(jīng)公開的提交對(duì)象，并且已經(jīng)有人基于這些提交對(duì)象開展了后續(xù)開發(fā)工作的話戏售，就會(huì)出現(xiàn)叫人沮喪的麻煩 |
- Git分支—遠(yuǎn)端同步
| git分支 — 和遠(yuǎn)端同步 | 文字描述 |
|---|---|
 image
|
如左圖箭頭中命名所示即可與遠(yuǎn)端同步 |
更多內(nèi)容請(qǐng)查看《幾張圖讓你徹底弄懂git工作流(三)——git深入》??
文章出處：起底Git & Pro Git
