一、引入
Git 分支管理是 Git 的另一杀手锏。其实分支的概念就像科幻电影里面的平行宇宙，可以让多个任务在不同的分支上并行进行。
- 实际开发中，引入分支可以将不同的功能或任务隔离开来，使得多个开发人员可以同时并行开发不同的功能，而不会相互干扰或冲突，可以提高团队的开发效率。
- 并且在引入分支还可以更好的进行风险控制，例如，新功能的开发和测试可以在独立的分支上进行，不会直接影响主分支的稳定性。如果功能开发出现问题，只影响到该分支，而不会对整个代码库造成影响。
- 并且在错误修复上也会更加方便。例如，如果在主分支上发现了错误或问题，可以创建一个临时分支进行错误修复。修复完成后，可以将修复后的代码合并回主分支，而不会干扰正在进行的其他工作。
二、创建合并分支
默认情况下，Git 中只有一个默认 master 分支，而之前介绍的 HEAD 其实就是指向默认分支 master 的。
- 查看分支：
git branch - 创建分支：
git branch <name> - 切换分支：
git checkout <name>或者git switch <name> - 创建+切换分支：
git checkout -b <name>或者git switch -c <name> - 合并某分支到当前分支：
git merge <name> - 删除分支：
git branch -d <name>
上面列举出了常用的分支命令，使用上述命令我们大概能得到如下流程：
但是注意这里的合并是“Fast-forward”快合并模式，也就是直接吧 master 指向 dev 的当前提交，所以速度非常快。
三、解决突。
对于合并分支时，可能会出现这样一种情况：我们在两个分支上的修改涉及到相同的文件或代码行，那么在分支合并的时候就会出现合并冲突。
当Git检测到冲突时，会在冲突发生的文件中插入特殊标记来指示冲突的位置。这些标记通常是<<<<<<<，=======和>>>>>>>。并且 Git 会告诉我们具体的冲突文件，此时我们可以通过查看冲突文件找到冲突内容，然后手动解决冲突后再次提交。
Tips：使用 git log --graph 命令可以看到分支合并图。
四、分支合并策略
上面我们介绍了，如果可能，默认情况下 Git 会用 Fast forward 模式进行分支合并。但通常情况下，我们合并分支之后通常会删除分支，这种情况下就会丢失分支信息，这个时候我们就看不出来最新提交到底是 merge 进来的还是正常提交的。
所以一般我们会禁用 Fast forward 模式，这样 Git 会在 merge 合并的时候生成一个新的 commit：
git merge --no-ff -m "message" <branch_name>
五、分支管理策略
在实际开发中，我们应该按照几个基本原则进行分支管理：
首先，master分支应该是非常稳定的，也就是仅用来发布新版本，平时不能在上面干活；
那在哪干活呢？干活都在dev分支上，也就是说，dev分支是不稳定的，到某个时候，比如1.0版本发布时，再把dev分支合并到master上，在master分支发布1.0版本；
你和你的小伙伴们每个人都在dev分支上干活，每个人都有自己的分支，时不时地往dev分支上合并就可以了。
六、Bug 分支
在实际开发中 Bug 可以说是司空见惯了，我们前面也已经见识到了 Git 的分支管理是非常强大的，所以每个 Bug 我们一般都会新建一个临时分支进行修复，修复完成后，再进行合并同时删除临时分支。
但是如果当前工作区中的代码只写了一半，还不能提交，并且这个 Bug 又非常紧急需要立即修改，这时该怎么办？幸好 Git 还提供了一个 stash 功能，可以把当前工作现场保存起来，等以后 Bug 修复完了再恢复现场继续工作。
上面涉及到保存现场和恢复现场，具体命令如下：
- git stash 保存工作现场
- git stash list 查看工作现场
- git stash apply 恢复后，stash内容并不删除，你需要用git stash drop来删除
- git stash pop 恢复的同时把stash内容也删了
假设我们的 Bug 是在 master 分支上修复的，那么此时 Master 分支目前最新的提交，是要领先于新建 dev2 时基于的 master 分支的提交的，所以我们在 dev2 中当然看不见修复 bug 的相关代码。如下图：
我们的最终目的是要让 master 合并 dev2 分⽀的，那么正常情况下我们切回 master 分⽀直接合并即可，但这样其实是有一定风险的。因为在合并分⽀时可能会有冲突，而代码冲突需要我们手动解决（在 master 上解决）。我们无法保证对于冲突问题可以正确地一次性解决掉，因为在实际的项目中，代码冲突不只一两行那么简单，有可能几十上百行，甚至更多，解决的过程中难免手误出错，导致错误的代码被合并到 master 上。
解决这个问题的一个好的建议就是：最好在自己的分支上合并下 master ，再让 master 去合并 dev ，这样做的⽬的是有冲突可以在本地分支解决并进行测试，而不影响 master 。
七、删除临时分支
软件开发中，总有⽆穷⽆尽的新的功能要不断添加进来。添加⼀个新功能时，你肯定不希望因为⼀些实验性质的代码，把主分搞乱了，所以，每添加⼀个新功能，最好新建⼀个分⽀，我们可以将其称之为 feature 分⽀，在上⾯开发，完成后，合并，最后，删除该 feature 分⽀。
可是，如果我们今天正在某个 feature 分⽀上开发了一半，被产品经理突然叫停，说是要停止新功能的开发。虽然白干了，但是这个 feature 分支还是必须就地销毁，留着无用了。这时使用传统的 git branch -d 命令删除分支的方法是不行的。于是有了如下方式：
git branch -D <branch_name>
