幾乎所有的版本控制系統(tǒng)都以分支的方式進(jìn)行操作谷朝，分支是獨(dú)立于項(xiàng)目主線的一條支線钞楼，我們可以在不影響主線代碼的情況下谅辣，在分支下進(jìn)行工作。對(duì)于傳統(tǒng)的一些版本控制工具來說前翎，我們通常需要花費(fèi)比較多的時(shí)間拷貝主線代碼稚配，創(chuàng)建一個(gè)分支，并且對(duì)分支的管理效率也越來越不令人滿意港华，而如今備受推崇的Git確實(shí)名副其實(shí)道川，Git中的分支非常輕量，我們可以隨時(shí)隨意創(chuàng)建任意數(shù)量的新分支立宜，幾乎感覺不到什么延時(shí)冒萄，而且對(duì)分支的操作也很高效，如橙数，切換分支尊流，暫存內(nèi)容，分支合并灯帮，分支提交等崖技。
Git分支的與眾不同
上面我們提到相對(duì)于其他大多數(shù)版本控制系統(tǒng)，Git分支是輕量且高效的钟哥，為什么呢响疚？答案是：傳統(tǒng)的版本控制系統(tǒng)存儲(chǔ)的數(shù)據(jù)是文件的變更，而Git則是存儲(chǔ)一系列的文件快照（snapshot）瞪醋。
Git分支的這些特性忿晕，使得分支對(duì)我們幾乎沒有什么限制，一般針對(duì)每一個(gè)功能或需求都可以隨意創(chuàng)建分支银受，而在傳統(tǒng)的版本控制系統(tǒng)践盼，這樣幾乎是不現(xiàn)實(shí)的。
當(dāng)我們向服務(wù)器提交數(shù)據(jù)時(shí)宾巍，Git會(huì)存儲(chǔ)一個(gè)提交對(duì)象（commit object）咕幻，這個(gè)存儲(chǔ)對(duì)象包括一系列有用信息，詳見另一篇文章中提交對(duì)象顶霞。
Git主干分支（master）
master肄程，有主人锣吼，大師的意思，在Git是通常作為主干分支蓝厌，Git初始化倉庫時(shí)玄叠，默認(rèn)創(chuàng)建的分支名就是master，就像默認(rèn)的遠(yuǎn)端主機(jī)別名是origin一樣拓提，大多數(shù)人不會(huì)修改它读恃，這并不說明它與別的分支有什么區(qū)別，你可以隨意修改名稱代态。
分支類型
在Git中寺惫，除了默認(rèn)的master主干分支，我們創(chuàng)建的每一個(gè)分支蹦疑，一般可分為兩種：
- 長(zhǎng)運(yùn)行分支（Long-Running branch）:與master并行西雀，長(zhǎng)期存在使用的分支，如用以測(cè)試項(xiàng)目穩(wěn)定性或作為主分支歉摧；
- 主題分支（topic branch）：針對(duì)每一個(gè)需求或功能或bug而暫時(shí)創(chuàng)建的分支蒋搜，一旦任務(wù)完成，即可能回收判莉。
分支指針（HEAD）
Git中有一個(gè)HEAD指針测摔，始終指向當(dāng)前分支带迟，如圖可見，項(xiàng)目當(dāng)前處在master分支项郊，之前一共有三次提交：
上圖可見膛檀，第一行顯示了當(dāng)前項(xiàng)目所有分支锰镀，HEAD -> master表明當(dāng)前所處分支為master，我們可以總結(jié)如下圖：
我們可以在項(xiàng)目根目錄.git文件下找到一個(gè)HEAD文件：vi .git/HEAD,其內(nèi)保存了指向當(dāng)前分支最新提交的指針：
該指針指向refs/heads/分支名文件咖刃，我們進(jìn)入.git/refs/heads/目錄泳炉，其下以分支名為文件名列出了所有分支：
我們查看當(dāng)前分支文件，執(zhí)行vi master:
可以看到嚎杨，其內(nèi)存儲(chǔ)的就是當(dāng)前分支的最新一次提交對(duì)象ID花鹅。
創(chuàng)建分支（git branch, git checkout -b）
接下來，假設(shè)有一個(gè)需求A枫浙，我們創(chuàng)建一個(gè)分支work-a:
git checkout -b 分支名
-b參數(shù)聲明為創(chuàng)建新分支刨肃。
等價(jià)于以下兩條指令：
git branch 分支名
git checkout 分支名
切換分支（git checkout）
git checkout 分支名表示切換到該分支，上文提到指定-b配置即說明創(chuàng)建新分支箩帚。
注：在切換分支前真友，一定確保當(dāng)前分支的修改已經(jīng)提交或者緩存。
多分支并行
我們經(jīng)常會(huì)遇到同時(shí)需要開發(fā)多個(gè)功能和需求紧帕，或者突然發(fā)現(xiàn)線上bug需要緊急處理盔然，我們只需要提交當(dāng)前分支修改，然后切換到主干分支，從其基礎(chǔ)上再切出一個(gè)新分支fix-bug1:
可以看到愈案，在work-a分支上我們新增了一次提交：
b287b8e22470b20cc98e6224a8023708b4cc6989挺尾。
現(xiàn)在我們?cè)趂ix-bug1分支上修復(fù)bug后，進(jìn)行提交：
可以看到刻帚，在fix-bug1分支上多了一個(gè)提交：ca270e6潦嘶，現(xiàn)在整個(gè)結(jié)構(gòu)就變成如下圖：
合并分支（git merge）
我們已經(jīng)修復(fù)了某bug或完成了功能開發(fā)，這時(shí)要做的是把代碼并入主干崇众，掂僵，當(dāng)然一般公司或團(tuán)隊(duì)都需要經(jīng)過代碼審查，才能并入主干顷歌，在此略過不談锰蓬，分支合并相關(guān)指令：
git merge 分支名
該指令告訴Git將指定分支合并到當(dāng)前分支，當(dāng)然是可能出現(xiàn)沖突的眯漩，我們按照指示解決沖突芹扭，即可。
現(xiàn)在我們先切換到master分支赦抖，然后把fix-bug1分支并入主干：
可以看到執(zhí)行g(shù)it merge指令后舱卡，狀態(tài)信息顯示：
- 第一行Updating，告訴我們提交記錄更新至ca270e6;
- 第二行Fast-forward队萤，即快速推進(jìn)轮锥，說明Git直接將當(dāng)前分支推進(jìn)到指向新提交對(duì)象;
- 后面是merge的內(nèi)容信息。
非快速推進(jìn)合并（NO FAST-FORWARD）
現(xiàn)在要尔，我們?cè)俅蝿?chuàng)建一個(gè)分支fix-bug2舍杜，并進(jìn)行幾次修改提交：
多次提交后，狀態(tài)如下：
我們通過非快速推進(jìn)方式合并分支進(jìn)主干分支：
如上圖赵辕，指定–no-ff即聲明進(jìn)行非快速推進(jìn)合并既绩，第二行的Merge made by the ‘recursive’ strategy表明通過非快速推進(jìn)方式合并，我們發(fā)現(xiàn)除了分支上進(jìn)行的提交記錄外还惠，Git創(chuàng)建了一個(gè)新的提交對(duì)象：7a657a,使用
git log –graph指令查看其信息:
如圖饲握，快速推進(jìn)方式合并入主干的fix-bug1分支的提交記錄直接并入主線，且不會(huì)創(chuàng)建新的提交對(duì)象蚕键；而對(duì)于非快速推進(jìn)方式合并的fix-bug2分支互拾，其提交歷史也都保存，但是并未進(jìn)入主線嚎幸，而是保存了一條支線颜矿，同時(shí)，在主線上創(chuàng)建一個(gè)新的提交對(duì)象嫉晶。
最后描述其結(jié)構(gòu)如圖：
非快速推進(jìn)與快速推進(jìn)合并（FAST-FORWARD & NO FAST-FORWARD）
從上例骑疆，對(duì)比一下兩種方式合并分支的異同：
- 提交對(duì)象都會(huì)保存田篇；
- 報(bào)存提交對(duì)象方式不同：快速推進(jìn)方式是直接在主線（合并主分支）上，添加這些提交對(duì)象箍铭，即直接移動(dòng)HEAD指針泊柬；而非快速推進(jìn)方式是將提交對(duì)象保存在支線，然后在主線新建一個(gè)提交對(duì)象诈火，修改HEAD指針及新建提交對(duì)象的指針兽赁，而且此新建提交對(duì)象有兩個(gè)父提交對(duì)象（即有兩個(gè)parent指針）。
- 合并后分支指向不同：快速推進(jìn)合并后冷守，兩個(gè)分支將同時(shí)指向最新提交對(duì)象刀崖，而非快速推進(jìn)合并后，合并主分支指向新建的提交對(duì)象拍摇，另一分支指向不變亮钦。
我們查看一下新創(chuàng)建提交對(duì)象：
可以看到該提交對(duì)象中有兩個(gè)指針指向父提交對(duì)象，一個(gè)指向主線中的父提交對(duì)象充活，一個(gè)指向fix-bug2分支合并而來的支線父提交對(duì)象蜂莉。
三路合并（THREE-WAY MERGE）
除了之前提到的兩種合并的情況，其實(shí)還存在這樣一種情況混卵，就是現(xiàn)在假如我完成了work-a分支的開發(fā)映穗，需要將其并入主干，我們能看到當(dāng)前master主干分支已經(jīng)推進(jìn)到7a6576了幕随，而work-a分支指向b287b8,兩者有共同祖先提交對(duì)象6d50f6,我們將其合并：
上圖第二行表明此次是通過非快速推進(jìn)方式合并蚁滋，我們查看提交對(duì)象記錄圖：
結(jié)構(gòu)如圖：
我們發(fā)現(xiàn)，三路合并結(jié)構(gòu)是在需要合并的兩個(gè)分支的最新提交對(duì)象的基礎(chǔ)上合陵，創(chuàng)建一個(gè)新提交對(duì)象(4ae14b)，將合并主分支（即執(zhí)行合并指令時(shí)澄阳，當(dāng)前所處分支）的HEAD指針前移指向該提交對(duì)象拥知，該提交對(duì)象有兩個(gè)父提交對(duì)象，分別為合并前待合并分支的最新提交對(duì)象（即b287b8和7a657a）碎赢。
關(guān)于三路合并需要明確：
- 三路合并其實(shí)是一種非快速推進(jìn)合并方式低剔；
- 三路合并的前提是兩個(gè)分支有共同祖先提交對(duì)象；
分支沖突（conflict）
在合并分支肮塞，不可避免會(huì)發(fā)生沖突襟齿，當(dāng)我們?cè)趦蓚€(gè)分支對(duì)同一文件同一部分進(jìn)行不同修改后，發(fā)起合并時(shí)就會(huì)提示有沖突枕赵，假設(shè)我們有work-b分支猜欺，在其基礎(chǔ)上切出新分支work-b-1，然后在兩分支上分別對(duì)README.md文件同一部分進(jìn)行不同修改并提交拷窜，然后將work-b-1分支合并到work-b分支：
發(fā)現(xiàn)README.md文件有沖突开皿，查看該文件：
如上圖涧黄，列出了兩個(gè)分支的不同修改，HEAD表明當(dāng)前分支的修改內(nèi)容赋荆，下面是work-b-1分支的修改笋妥，我們選擇需要保留的內(nèi)容，刪除其他無關(guān)信息和內(nèi)容窄潭，然后保存該文件春宣，查看當(dāng)前狀態(tài)：
根據(jù)提示，解決沖突后提交：
查看分支
對(duì)于創(chuàng)建過但并未刪除的分支嫉你，我們可以查看分支列表月帝，依然使用git branch指令，不傳入任何參數(shù)：
圖中列出了所有分支均抽，前面帶星號(hào)的表示當(dāng)前分支嫁赏，當(dāng)然我們還可以查看指明最新提交信息的分支列表，可以添加-v參數(shù)：
篩選分支
除了可以查看所有分支列表油挥，Git還支持篩選已合并或未合并至當(dāng)前分支的所有分支：
- –merged參數(shù)指明篩選已合并分支潦蝇；
- –no-merged參數(shù)指明篩選未合并分支。
刪除分支（git branch -d）
當(dāng)分支合并入主干后深寥，也許我們不再需要那個(gè)分支了攘乒，我們需要將其刪除，使用指令：
git branch -d 分支名
之前介紹到使用git branch是創(chuàng)建新分支惋鹅，而指定-d參數(shù)则酝，說明需要?jiǎng)h除該分支：
遠(yuǎn)程分支（remote branch）
我們注意到，前文所講述的分支都是存在本地的闰集，即本地分支沽讹，還需要了解遠(yuǎn)程分支，如[remote]/[branch]這種形式武鲁，表示是遠(yuǎn)端主機(jī)的某分支爽雄，關(guān)于遠(yuǎn)端主機(jī)詳情請(qǐng)查看，其實(shí)遠(yuǎn)程分支和本地分支基本理論概念還是相同的沐鼠，區(qū)別是有些指令不同而已：
git checkout -b test origin/develop
以上指令即從遠(yuǎn)程分支(遠(yuǎn)端主機(jī)origin上的develop分支)切出新的本地分支test分支挚瘟。
跟蹤分支（TRACKING BRANCH）
前文已經(jīng)介紹了本地分支和遠(yuǎn)程分支的概念及操作，那么這兩類分支之間應(yīng)該有某種關(guān)系將他們關(guān)聯(lián)起來饲梭，本地項(xiàng)目都需要與遠(yuǎn)端主機(jī)倉庫同步（pull & push）,當(dāng)我們從一個(gè)遠(yuǎn)程分支切出（創(chuàng)建）一個(gè)本地分支時(shí)乘盖，這個(gè)分支就叫跟蹤分支（tracking branch）,而遠(yuǎn)程分支叫上游分支（upstream branch）。
當(dāng)我們克隆一個(gè)遠(yuǎn)端倉庫時(shí)憔涉，會(huì)默認(rèn)創(chuàng)建一個(gè)跟蹤分支master订框，其上游分支就是遠(yuǎn)端主機(jī)別名/master。
創(chuàng)建跟蹤分支
創(chuàng)建跟蹤分支指令如下：
git checkout -b 本地分支名 遠(yuǎn)端主機(jī)別名/遠(yuǎn)程分支名
當(dāng)然也可以不指定分支名兜叨，使用遠(yuǎn)程分支同名：
git checkout --track 遠(yuǎn)端主機(jī)別名/遠(yuǎn)程分支名
修改跟蹤關(guān)系
有時(shí)候布蔗，可能需要為本地分支設(shè)置其上游分支藤违，添加-u參數(shù)：
git branch -u 遠(yuǎn)端主機(jī)別名/遠(yuǎn)程分支名
以上指令就指明當(dāng)前分支跟蹤某遠(yuǎn)端主機(jī)的遠(yuǎn)程分支。
查看跟蹤分支（git branch -vv）
使用以下指令查看分支的上游分支：
git branch -vv
上圖輸出信息第二行表明master分支跟蹤遠(yuǎn)程origin/master分支纵揍，ahead 7表明本地有7個(gè)提交未推到服務(wù)器顿乒，其他分支不是跟蹤分支，沒有上游分支泽谨。
刪除遠(yuǎn)程分支
對(duì)于不再需要的遠(yuǎn)程分支璧榄，是可以刪除的：
git push origin --delete test
以上指令刪除遠(yuǎn)端主機(jī)origin的test分支，但是在垃圾回收之前吧雹，Git服務(wù)器仍然會(huì)保留分支數(shù)據(jù)骨杂，我們可以很方便的恢復(fù)數(shù)據(jù)，之后會(huì)詳細(xì)介紹雄卷。
變基（rebase）
Git中有兩種方式整合不同分支的修改：第一種是前文介紹的合并（merge）搓蚪，另一種就是本節(jié)的主題變基（rebase）。
變基其實(shí)與前文提到的三路合并（three-way merge）頗有淵源：
如圖work-a分支與主干master分支合并后丁鹉，創(chuàng)建一個(gè)新提交對(duì)象妒潭，我們還可以通過變基完成兩個(gè)分支的修改整合，由于work-a分支已合并到master分支揣钦，我們?cè)趙ork-a分支再提交一次修改e0ae7dc,然后我們將work-a分支對(duì)master分支進(jìn)行變基：
執(zhí)行變基時(shí)雳灾，由于兩個(gè)分支對(duì)同一文件同一部分進(jìn)行了不同修改，會(huì)提示沖突冯凹，需要解決沖突谎亩，我們修改文件解決沖突，然后查看狀態(tài)：
上圖宇姚，第一行rebase in progress; onto 4ae14b3說明當(dāng)前分支針對(duì)4ae14b3快照進(jìn)行變基匈庭，第三到第五行分別說明：
- 第三行：解決沖突然后執(zhí)行g(shù)it rebase –continue指令繼續(xù)變基；
- 第四行：執(zhí)行g(shù)it rebase –skip指令浑劳，跳過解決沖突阱持；
- 第五行：執(zhí)行g(shù)it rebase –abort指令，終止變基呀洲，回到分支變基前狀態(tài)紊选。
下面第6到第八行說明：
- 第七行：使用git reset HEAD 指令撤銷某文件變更啼止；
- 第八行：使用git add 指令標(biāo)記沖突為已解決狀態(tài)道逗。
最后一行no changes added to commit (use “git add” and/or “git commit -a”)，說明尚未標(biāo)記沖突献烦，需要使用指令標(biāo)記變更滓窍，在繼續(xù)執(zhí)行變基：
如上圖，變基后巩那，在主線上創(chuàng)建新提交對(duì)象640b83,并修改work-a分支指針指向該提交對(duì)象：
之后我們可以正常的合并：
變基后合并
如圖吏夯，主線分支更新提交對(duì)象到640b83a此蜈，第二行Fast-forward說明此次合并屬于快速推進(jìn)合并方式，結(jié)構(gòu)如下：
三路合并與變基
基于上例噪生，三路合并裆赵，整合修改變更后會(huì)保留分支的原始提交記錄，新創(chuàng)建提交對(duì)象有兩個(gè)父提交對(duì)象跺嗽，一個(gè)在主線上战授，一個(gè)在待合并分支上；而變基則不能保留待合并分支的原始提交記錄桨嫁，主線上新建的提交對(duì)象只有一個(gè)位于主線上的父提交對(duì)象植兰。更多變基相關(guān)內(nèi)容計(jì)劃單獨(dú)出文介紹。
至于到底選用哪種方式整合變更璃吧，變基還是合并楣导，這個(gè)一直有爭(zhēng)論，沒有哪一種方式絕對(duì)合理畜挨，我們只需要把握一個(gè)原則：無論變基還是合并筒繁，你應(yīng)該只操作本地歷史記錄，任何已經(jīng)推到服務(wù)器并入主干的內(nèi)容和提交歷史不應(yīng)該更改朦促。
