1. 分支
在 Git 中，分支（Branch）是用于在项目中创建独立开发线路的机制。分支使得开发者可以在不影响主干（main 或 master）的情况下进行实验、开发新功能或修复 Bug。
举个例子：
分⽀就好像是科幻电影⾥⾯的平⾏宇宙，当你正在电脑前努⼒学习 C++ 的时候，另⼀个你正在另⼀个平⾏宇宙⾥ 努⼒学习 Python。
如果两个平⾏宇宙互不⼲扰，那对现在的你也没啥影响。不过，在某个时间点，两个平⾏宇宙合并了，结果，你既学会了 C++ ⼜学会了 Python！
现实世界，在Git分支对应得就是主分支，而平行时间，在Git里面对应得就是新创建得另一个分支。
在Git中，每进行一次提交(commit操作)，Git都把它们串成⼀条时间线，这条时间线就可以理解为是⼀个分⽀。如果只有一条分支，在Git里，这个分支就是主分支，即master分支。
而HEAD，HEAD 严格来说不是指向提交，⽽是指向master，master才是指向提交的，所以，HEAD 指向的就是当前分⽀。
每次提交，master分⽀都会向前移动⼀步，这样，随着你不断提交，master分⽀的线也越来越⻓,⽽ HEAD只要⼀直指向master分⽀即可指向当前分⽀
1.1 创建分支
Git ⽀持我们查看或创建其他分⽀，在这⾥我们来创建第⼀个⾃⼰的分⽀ dev ，对应的命令为：
git branch 分支名
使用示例
- 创建dev分支
git branch dev
然后使用git branch可以查看所有分支。
当我们创建新的分⽀后，Git 新建了⼀个指针叫 dev， * 表⽰当前 HEAD 指向的分⽀是 master分⽀。另外，可以通过⽬录结构发现，新的 dev分⽀和 master 指向同⼀个提交。
图解：
1.2 切换分支
使用 git checkout 分支名 命令切换到指定分支。
使用示例
比如切换到dev分支。
git checkout dev
切换到dev分支后，就可以看到*在dev分支前，表明当前分支是dev分支。
切换分支后，HEAD就指向到切换得分支下面了。
可以使用cat .git/HEAD进行验证
切换分支后，在dev分支下进行操作，比如新建一个文件test.txt,然后向其进行随便写入一些东西。
写入完成后，在dev分支下面进行一次提交操作
git add .
git commit -m "dev commit tset"
提交完成后，切换到master分支下面
git checkout master
切换到master分支后，就发现test.txt文件不存在了。 然后继续切回到dev分支下，发现，在dev分支下，test.txt文件还存在的。
出现这个现象的原因就是：我们是在dev分⽀上提交的，⽽master分⽀此刻的提交点并没有变。
使用命令可以查看他们的指向是不同的：
图解如下：
当切换到 master 分⽀之时，HEAD 就指向了 master，自然就看不到test.txt文件了。
1.3 合并分支
为了在 master 主分⽀上能看到新的提交，就需要将 dev 分⽀合并到 master 分⽀。
使用git merge⽤于合并指定分⽀到当前分⽀。
使用案例
将dev分支合并到master分支下。
- 必须切换到master分支下进行合并
- 使用
git merge dev将dev分支合并到master分支下。
此时 就能在master分支下看到test.txt文件了。
Fast-forward 代表“快进模式”，也就是直接把master指向dev的当前提交，所以合并速度⾮常快。
图解：
1.4 删除分支
合并完成后, dev 分⽀对于我们来说就没⽤了， 那么dev分⽀就可以被删除掉。
注意：不能在dev分支下删除dev分支，也就是不能自杀。
删除分支的命令
git branch -d 分支名
使用案例
- 删除dev分支
git branch -d dev
删除后的图解：
因为创建、合并和删除分⽀⾮常快，所以Git官方建议使⽤分⽀完成某个任务，合并后再删掉分⽀，这和 直接在master分⽀上⼯作效果是⼀样的，但过程更安全。
2. 冲突
可是，在实际分⽀合并的时候，并不是想合并就能合并成功的，有时候可能会遇到代码冲突的问题。
下面就演示一下这种场景：
先创建一个测试分支dev。
使用git checkout -b dev创建切换分支。这个命令就是切换到dev分支，如果分支不存在，就创建。
在dev分支下，修改test.txt文件。向test.txt文件写入一行新文本modify by dev
在dev分支下进行提交。(先add添加，在使用commit进行提交)
切换到master分支下。
在master分支下，查看test.txt文件中的内容，此时是没有更新的。
在master分支下，也对test.txt文件中进行修改如下：
修改完成后，在master分支下进行提交。
现在，master和dev分支下都分别有了自己新的提交。图示如下：
在这种情况下，Git只能试图把各⾃的修改合并起来，但这种合并就可能会产生合并冲突。
在master分支下合并dev分支，下面这种情况就出现了合并冲突。
此时 查看test.txt文件中的内容就会看到，git会用指定的字符<<<<<<<，=======， >>>>>>> 来标记不同分支出现冲突的内容。如下：
2.1 合并冲突
当发生合并冲突的时候，就需要我们手动调整冲突的代码，保留需要的一部分，删除不需要的一部分。然后再次进行提交调整后的代码。(必须要再次提交)
此时，图示状态如下：
使用git log也能查看分支合并的情况。
git log --graph --pretty=oneline --abbrev-commit
合并完了，dev分支也就不用了，删除即可。使用git branch -d dev删除dev分支即可。
3. 分支管理策略
在合并分支的时候，Git一般会采用Fast forward模式，直接把master指向dev的当前提交。如果采用Fast forwrad模式后，形成的合并结果如下：
在这种 Fast forward 模式下，删除分⽀后，查看分⽀历史时，会丢掉分⽀信息，看不出来最新提 交到底是 merge 进来的还是正常提交的。
但在合并冲突部分，我们也看到通过解决冲突问题，会再进行⼀次新的提交，得到的最终状态为：
那么这就不是 Fast forward 模式了，这样的好处是，从分⽀历史上就可以看出分⽀信息。
Git ⽀持我们强制禁⽤ Fast forward 模式，那么就会在 merge 时⽣成⼀个新的 commit ，这样， 从分⽀历史上就可以看出分⽀信息。
使用示例 - 非Fast forward模式进行合并
1、创建一个新的dev分支，切换到新分支下。
git checkout -b dev
2、修改test.cc，并提交⼀个新的 commit。
3、切换到master分支，开始合并。
–no-ff 参数，表⽰禁⽤ Fast forward 模式。禁⽤ Fast forward 模式后合并会创建 ⼀个新的 commit ，所以加上 -m 参数，把描述写进去。
4、合并后，查看历史分支日志
这样，在合并分支的时候，加上 --no-ff 参数就可以⽤普通模式合并，合并后的历史有分⽀，能看出来曾 经做过合并，⽽ Fast Forward 合并就看不出来曾经做过合并。
3.1 分支策略
在实际开发中，应该按照以下⼏个基本原则进⾏分⽀管理：
- ⾸先，master分⽀应该是⾮常稳定的，也就是仅⽤来发布新版本，平时不能在上⾯⼲活；
- ⼲活都在dev分⽀上，也就是说，dev分⽀是不稳定的，到某个时候，⽐如1.0版本发布 时，再把dev分⽀合并到master上，在master分⽀发布1.0版本
- 团队里每个⼈都在dev分⽀上⼲活，每个⼈都有⾃⼰的分⽀，时不时地往dev分⽀上合并就 可以了。
- 团队合作的分支看起来就像下图一样：
4. Bug分支
假如我们现在正在 dev 分⽀上进⾏开发，开发到⼀半，突然发现 master 分⽀上⾯有 bug，需要解决。在Git中，每个bug都可以通过⼀个新的临时分⽀来修复，修复后，合并分⽀，然后将临时分⽀删除。
可现在 dev分支的代码在⼯作区中开发了⼀半，还⽆法提交。比如下面这种情况：
针对这种情况，Git 提供了git stash命令。可以将工作区的信息进行储藏，，被储藏的内容可以在将来某个时间恢复出来。比如在dev分支下，将当前的工作区进行储藏。
储藏之后，查看工作区的状态就是干净的了。
储藏dev分支后，就要对master分支下的bug进行修复了。所以需要切回到master分支下。在创建临时分支修复bug。
修复完bug后，在dev分支下 重新add commit。
然后切换到master分支下，完成合并。最后删除bug分支即可。
至此，bug修复的工作已经完成，继续回到dev分支下进行开发。首先切换到dev分支下。
由于修复bug之前，将dev分支下的工作区代码进行储藏了，现在就要对其进行恢复了。
使⽤ git stash pop 命令进行恢复，恢复的同时会把 stash 也删了。
这样，dev分支下的工作区就之前的写的代码就被恢复了。
恢复现场也可以采⽤
git stash apply恢复，但是恢复后，stash内容并不删除，需要⽤git stash drop来删除。也可以多次stash，恢复的时候，先⽤
git stash list查看，然后恢复指定的stash，⽤命令 git stash apply stash@{0}。
恢复完代码后，就可以继续完成开发了，开发完成后进行提交即可。
但是，在dev分支下，修复bug的内容，并没有在dev分支下显示，此时的状态图如下：
现在要切换到master分支下合并dev分支。正常情况下，切回到master分支下，直接合并即可。但这样其实是有⼀定⻛险的。
是因为在合并分⽀时可能会有冲突，⽽代码冲突需要我们⼿动解决（在 master 上解决）。我们⽆法 保证对于冲突问题可以正确地⼀次性解决掉，因为在实际的项⽬中，代码冲突不只⼀两⾏那么简单， 有可能⼏⼗上百⾏，甚⾄更多，解决的过程中难免⼿误出错，导致错误的代码被合并到 master 上。 此时的状态为：
解决这个问题的⼀个好的建议就是：最好在⾃⼰的分⽀上合并下 master ，再让 master 去合并 dev ，这样做的⽬的是有冲突可以在本地分⽀解决并进⾏测试，⽽不影响 master 。此时的状态为：
在dev分支下合并master,就算合并有问题，也可以在dev分支下进行多次修改测试，不会影响master分支下的代码。
然后再去master分支下去合并dev分支。此时冲突在dev分支下已经解决了，在master分支下进行合并就无需解决冲突了~。
实操如下：
5. 删除临时分支
添加⼀个新功能时，你肯定不希望因为⼀些实验性质的代码，把主分⽀搞乱了，所以，每添加⼀个新功能，最好新建⼀个分⽀，我们可以将其称之为 feature 分⽀，在上⾯开发，完成后，合并，最后，删除该 feature 分⽀。
可是，如果我们今天正在某个 feature 分⽀上开发了⼀半，被产品经理突然叫停，说是要停⽌新功能的开发。虽然⽩⼲了，但是这个 feature 分⽀还是必须就地销毁，留着⽆⽤了。这时使⽤传统 的 git branch -d命令删除分⽀的⽅法是不⾏的。
比如：在新的feature分支下开发新功能。
此时新功能被叫停，切回master分支准备删除feature分支。
根据提示也可以看到，要使用-D选项进行删除。
6. 总结
⽀在实际中有什么⽤呢？
- 你准备开发⼀个新功能，但是需要两周才能完成，第⼀周你写了50% 的代码，如果⽴刻提交，由于代码还没写完，不完整的代码库会导致别⼈不能⼲活了。
- 如果等代码全部写完再⼀次提交，⼜存在丢失每天进度的巨⼤⻛险。
- 现在有了分⽀，就不⽤怕了。你创建了⼀个属于你⾃⼰的分⽀，别⼈看不到，还继续在原来的分⽀上正常⼯作，⽽你在⾃⼰的分⽀上⼲活，想提交就提交，直到开发完毕后，再⼀次性合并到原来的分⽀ 上，这样，既安全，⼜不影响别⼈⼯作。
- 并且 Git ⽆论创建、切换和删除分⽀，Git在1秒钟之内就能完成！⽆论你的版本库是1个⽂件还是1万个⽂件。
