上篇文章已经说了Git简史以及Git基础，那么这篇文章简单总结下Git分支
Git分支
为了理解 Git 分支的实现方式,我们需要回顾一下,
Git保存的不是文件差异或者变化量，而只是一系列文件快照.
- Git分支
| 分支其实就是从某个提交对象往回看的历史 | 文字描述 |
|---|---|
image
|
Git中的分支，本质上就是个指向master对象的可变指针，master为默认分支，每次提交都会向前移动 |
| 多个分支指向提交数据的历史 | 文字描述 |
|---|---|
image
|
Git创建一个新分支指针从而创建分支，创建testing命令git branch testing |
| HEAD 指向当前所在的分支 | 文字描述 |
|---|---|
image
|
Git因为保存一个名为HEAD的指针，它指向正在工作中本地分支指针 git branch仅是创建新分支，但不会自动切换分支中去（如图还在master上） |
| HEAD 在你转换分支时指向新的分支 | 文字描述 |
|---|---|
image
|
运行git checkout testingHEAD就指向testing分支了 |
| 每次提交后 HEAD 随着分支一起向前移动 | 文字描述 |
|---|---|
image
|
左图是又提交一次的结果，每次提交后HEAD随着分支一起向前移动 但master仍指向原来git checkout时所在的commit对象。再次执行git checkout masterHEAD才会指向master |
- Git—merge
| 分支的合并 — merge #1 | 文字描述 |
|---|---|
image
|
1. #53是第一滴修补问题的分支 git chackout -b iss53 === git branch iss53+git checkout iss53 2.假如接到紧急任务，这时候就不必花费大力气来复原这些修改，执行git checkout master创建紧急修补分支git checkout -b hotfix 3.hotfix分支是从master分支所在点分化出来的 |
image
|
1.测试成功后回到master把它合并起来，然后发布服务器，命令为git checkout master git merge hotfix 合并会出现“Fast forward”的提示 2.因为是master并入hotfix的直接上游，只需master指针右移动（顺着走）称为快进 3.合并之后，master 分支和 hotfix 分支指向同一位置 |
| 分支的合并 — merge #2 | 文字描述 |
|---|---|
image
|
1.现在回来处理iss53，完成后合并回master,不同于hotfix,开发历史从早的地方开始分叉的 2.master->c4，git额外处理为找到共同祖先C2简单三方合并 |
image
|
三方合并后的结果重新快照，并自动创建指向它的提交对象C6,可以看到C6有两个祖先 (git自动创建了一个包含了合并结果的提交对象，自己裁决哪个共同祖先才是最佳合并基础，这和 CVS及Subversion（1.5 以后的版本不同) |
- Git—rebase
| 分支的合并 — rebase #1 | 文字描述 |
|---|---|
image
|
把一个分支中的修改整合到另一个分支的办法有两种：merge 和 rebase（衍合） 如左图：分叉到两个不同分支，又各自提交了更新 |
image
|
除了merge两个分支最新的公共祖先三方合并 另外就是C3的变化补丁在C4中重新打一遍->衍合 有了衍合可以把分支中提交的变化移到另一个分支重放一遍 （原理：回到共同祖先，根据当前分支（ex··）提交的对象C3,生成补丁然后以master最后提交的C4为新的出发点，逐个应用之前准备好的补丁文件，最后会生成一个新的合并提交对象（C3'），master成直接下游） |
image
|
回到master进行快进合并 |
| 分支的合并 — rebase #2 | 文字描述 |
|---|---|
image
|
从一个特性分支里再分出一个特性分支的历史 服务器端代码添加功能创建server提C3C4->从C3增加client分支并提C8C9->回server提C10 |
image
|
将特性分支上的另一个特性分支衍合到其他分支 一次软件发布中，我们决定先把客户端的修改并到主线中，而暂缓并入服务端软件的修改 git rebase --onto master server client 取出 client 分支，找出 client 分支和 server 分支的共同祖先之后的变化，然后把它们在 master 上重演一遍 |
image
|
快进 master 分支，使之包含 client 分支的变化 git checkout master git merge client |
image
|
在 master 分支上衍合 server 分支 git rebase [主分支] [特性分支] 命令会先取出特性分支 server，然后在主分支 master 上重演 git rebase master server |
image
|
最终的提交历史 快进主干分支 master git checkout master && git merge server |
现在 client 和 server 分支的变化都已经集成到主干分支来了，可以删掉它们了
git branch -d client
git branch -d server
- Git—rebase风险
| 分支的合并 — rebase的风险 | 文字描述 |
|---|---|
| 把衍合当成一种在推送之前清理提交历史的手段，而且仅仅衍合那些尚未公开的提交对象，就没问题。 | 如果衍合那些已经公开的提交对象，并且已经有人基于这些提交对象开展了后续开发工作的话，就会出现叫人沮丧的麻烦 |
- Git分支—远端同步
| git分支 — 和远端同步 | 文字描述 |
|---|---|
image
|
如左图箭头中命名所示即可与远端同步 |
更多内容请查看《几张图让你彻底弄懂git工作流(三)——git深入》?
文章出处：起底Git & Pro Git
更多文章： https://xiaodian-li.github.io/
网友评论