为什么需要分支
问题情景：开发人员在开发一个新功能，需要两天完成，第一天完成 50%，如果当天提交，由于代码还没写完，不完整的代码库会导致别人不能干活了。如果等代码全部写完再一次提交，又存在丢失第一天进度的巨大风险。
解决方案：创建了一个属于你自己的分支，别人看不到，别人可以继续在原来的分支上正常工作，而你在自己的分支上干活，想提交就提交，直到开发完毕后，再一次性合并到原来的分支上。
Git 分支的生命周期
我们知道，每次提交，
Git都把它们（提交）串成一条时间线，这条时间线就是一个分支。最开始只有一条时间线，在Git里，这个分支叫主分支，即master分支。HEAD严格来说不是指向提交，而是指向master，master才是指向提交的，所以，HEAD指向的就是当前分支。
初始化后
一开始的时候，master分支是一条线，Git用master指向最新的提交，再用HEAD指向master，从而Git通过HEAD就能确定当前分支，以及当前分支的提交点。每次提交，master分支都会向前移动一步，这样，随着你不断提交，master分支的线也越来越长。
after_init.png
创建并切换到新分支
当我们创建新的分支，例如dev时，Git新建了一个指针叫dev，指向master相同的提交，再把HEAD指向dev，就表示当前分支在dev上（切换分支）。在Git中创建一个分支很快，因为除了增加一个dev指针（创建新分支），改改HEAD的指向（切换到新分支），工作区的文件都没有任何变化！
new_branch.png
新分支上提交
不过，从现在开始，对工作区的修改和提交就是针对dev分支了，比如新提交一次后， dev指针往前移动一步，而master指针不变。
new_branch_commit.png
合并分支
假如我们在dev上的工作完成了，就可以把dev合并到master上。Git 怎么合并呢？最简单的方法，就是直接把master指向dev的当前提交，就完成了合并。所以Git合并分支也很快！就改改指针，工作区内容也不变！
merge_branch_01.png
删除分支
合并完分支后，可以删除dev分支。删除dev分支就是把dev指针给删掉，删掉后，我们就剩下了一条master分支：
delete_branch.png
Git 分支的合并
情景1
在master分支上，创建并切换到新的分支dev，在dev分支做了修改并提交后，又切换回到master分支，如何在master分支上合并dev分支？
new_branch_commit.png
解决方案：直接使用git merge dev命令将dev分支合并到master分支（当前分支）上，此时采用的是一种Fast-forward（快进模式）的合并方式，也就是直接将master指向 dev的当前提交。
merge_branch_01.png
情景2
Git用Fast forward模式合并分支后，如果删除分支，会丢掉分支信息，如何保留分支信息？
delete_branch.png
解决方案：强制禁用Fast forward模式（参数--no-ff），此时Git就会在合并时生成一个新的提交，这样，从分支历史上就可以看出分支信息。强制禁用Fast forward模式的命令git merge --no-ff -m "merge with no-ff" dev。
merge_branch_02.png
情景3
在master分支创建并切换到新的分支dev，在dev分支做了修改并提交，然后切换回到master分支，在master分支上也做了修改并提交（且修改的内容与在 dev分支修改的内容发生冲突），如何合并分支？
git_conflict.png
解决方案：如果直接使用git merge dev命令，Git将报告文件存在冲突，此时必须手动解决冲突后再提交。
git_conflict_solve.png
情景4
当前正在 dev分支上工作，但工作还未完成，无法提交，但同时需要修复另外一个新的 bug，怎么办？
解决方案：将当前dev分支（有修改当没有提交）的工作现场储藏起来，等以后恢复现场后再继续工作
分支策略
-
master分支：master分支应该是非常稳定的，也就是仅用来发布新版本，平时不能在上面干活 -
dev分支：干活都在dev分支上，比如1.0版本发布时，再把dev分支合并到master上，在master分支发布1.0版本 -
bug分支：bug分支常用于修复某一个 Bug， -
feature分支：feature分支常用于开发某一个新功能
branch_types.png
参考：廖雪峰的 Git 教程
网友评论