目录
分支管理介绍
分支管理 是Git 的重要功能之一，能够把不同功能、不同阶段的开发工作隔离 在不同分支 ，互不干扰，完成后再合并到主分支
在上一篇文章（Git 基本操作-CSDN博客）中，我们看到，在创建 Git 仓库时，会自动创建 master 分支，而对于每一次提交，Git 会将它们串成一条提交时间线：
HEAD 指向master，master 指向提交，每次提交，master 分支都会向前移动一步，因此，随着不断提交，master 分支的提交线越来越长
除了 master 分支，我们也可以自己创建分支
创建分支
首先，我们可以通过 git branch 命令，查看当前本地的所有分支：
当前只有 master 分支，我们可以通过**git branch [branchname]**来创建对应分支：
那么，新创建的 dev 分支指向哪里呢？
我们查看**.git/refs/heads/** 下的分支，并查看存储的commit id：
可以发现，dev 和 master 中存储的commit id 相同，即，dev 和 master指向同一个修改：
我们查看 HEAD：
可以看到此时 HEAD 仍然指向 master ，那么，我们如何切换到 dev 分支呢？
切换分支
我们可以使用git checkout命令来进行分支切换：
可以看到，此时***** 标记在 dev 分支上，表示当前在 dev 分支，且 HEAD 中存储的也是 dev，而不是 master：
接下来，我们在dev 分支下修改test 文件，再进行提交操作：
此时，我们再切换回 master 分支，并查看 test 文件内容：
可以看到，在 dev 上的修改并未同步到 master 分支上，我们查看此时 dev 分支和 master 分支指向的提交：
dev 分支指向的提交已经发生了改变，这是因为我们在 dev 分支上新进行了提交，而 master 分支此时的提交并没有改变：
那么，如果我们想要在 master 分支上也能够看到新的修改，该如何做呢？
合并分支
想要能在 master 分支上看到新的修改提交，需要将 dev 分支合并到 master 分支
我们需要保证当前在master 分支上，再通过git merge [targetbranch] 命令来合并目标分支，也就是 dev 分支：
此时，我们就能够看到 dev 分支提交的内容了，当前的状态为：
我们看到在 master 分支合并 dev 分支时，显示Fast-forword ，代表本次合并模式为 "快进模式" ，也就是直接修改 master 的指向为 dev 的当前提交，因此合并速度非常快
通过查看 dev 和 master 指向的提交，我们就可以看到，此时 master 与 dev 的指向相同，都为 dev 的最新提交：
在合并完成之后，dev 分支也就没什么作用了，此时就可以删除 dev 分支，那么，该如何删除分支呢？
删除分支
我们可以通过git branch -d [branchname] 来删除指定分支，但需要注意的是 不能删除当前所处分支：
因此，要删除 dev 分支，我们需要切换到 master 分支，再进行删除：
此时就只剩 master 分支了：
上述我们在合并分支时，非常的顺利，但是，在实际合并分支时，可能会遇到一些问题
合并冲突
我们创建一个新的分支 dev1，并在 dev1 分支下修改 test 文件，再进行提交：
再切换回 master 分支，此时，由于 master 分支未合并 dev1 分支，因此，test 中无 dev1 新修改内容：
若我们此时再对 test 文件进行修改，并进行提交：
此时，master 分支和 dev1 分支各自分别有了新的提交：
此时，若我们再想将 dev1 分支合并到 master 分支，就可能会出现冲突：
我们可以看到，在合并过程中，test 文件发生冲突，自动合并失败。需要修复冲突，再重新提交结果，我们查看 test 文件：
Git 会使用**<<<<<<<、======= 和 >>>>>>>** 来标记处不同分支的冲突内容
此时，我们需要手动调整冲突内容 ，并再次提交修改后结果：
此时，冲突就解决完成了：
此外，我们可以使用带参数的git log 命令查看分支合并情况：
git log --graph --pretty=oneline --abbrev-commit
--graph：用 ASCII 图形画出分支合并关系，直观展示不同分支的提交脉络
--pretty=oneline ：把每个提交压缩成单行输出，只保留核心信息，让日志更紧凑
--abbrev-commit ：只显示提交哈希的短版本，让输出更简洁
最后，我们删除 dev1 分支：
分支合并策略
在合并分支时，如果可能，Git 会采用 Fast forward模式：
在 Fast forward 模式下，删除分支后，再查看分支历史时，就不能看出提交是merge 进来 的还是 master 正常提交的，例如，合并 dev 时：
而我们在合并 dev1 时，合并过程中发生了冲突，而我们解决这个冲突之后，再次进行了一次新提交：
上述模式就不是 Fast forward 模式了，但我们可以从分支历史上清晰看出分支信息，此时及时我们删除了 dev1 分钟，也依旧可以看到 master 分支合并了其他分支：
那么，如果我们想使用上述非 Fast forward 模式，来帮助我们更清晰的显示合并过程，该如何实现呢？
我们可以在合并时使用git merge --no-ff -m "message" [mergename] 来强制禁止 Fast forward 模式
例如，我们再创建一个 dev2 分支，进行修改后，再合并至 master 分支：
此时，就会在 merge 时生成一个新的 commit，此时，我们就可以在分支历史上看出分支信息：
即：
因此，在合并分支时，使用**--no-ff** 参数就可以使用普通模式 合并，合并后的历史有分支情况，可以看出曾经做个合并，而 Fast forward 合并就看不出曾经做个合并
分支策略
在实际开发过程中，我们应该按照以下结果基本原则来进行分支管理：
保持master 主分支稳定 ，任何时候主分支，都应该是可编译、可测试、可发布的状态，也就是说，master 主分支上仅用于版本发布，而不在上面完成开发工作
保证任务隔离，一个功能/修复对应一个分支，不混放不同任务的代码
3.分支任务完成后，及时进行合并，避免长期分支，减少大规模合并冲突
团队之间的合作分支情况：
修改暂存
我们来看一个例子：假设此时在 dev3 分支上进行开发，开发到一半，突然发现 master 分支上存在 bug，需要紧急进行修复，因此，我们需要创建一个新的临时分支来修复该 bug ，修复完成后再合并到 master 分支
但是，现在 dev2 分支上的代码在工作区上开发了一半，还未进行提交，又不想带着这些修改切换分支，此时该怎么办？
我们可以使用 git stash 命令，将当前工作区未完成的修改暂时贮藏起来：
可以看到，此时工作区变得非常干净，为了方便识别我们每次贮藏的内容，可以为其添加说明信息：
可以使用git stash list来查看所有贮藏列表：
最新的贮藏位于最上方，编号是stash@{0}，越久编号越大
此时，我们再切回 master 分支，并创建临时分支来修复 bug：
使用**git checkout -b [branchname]**可新建并切换到目标分支
我们再在 fix_bug 分支上进行修改，修改完成后，再进行提交：
此时，再将其进行合并：
至此，bug 就已经修复完成了，可以删除 fix_bug 分支，我们需要继续回到 dev3 分支上继续进行开发：
但是，由于我们直接将工作区的修改暂存了起来，此时工作区是干净的
那么，我们如何恢复之前的修改呢？
可以使用git stash pop 命令来恢复最新的贮藏 （也就是stash@{0}），它会同时将其从贮藏列表移除：
若我们想恢复指定贮藏，可使用命令：git stash pop stash@{指定编号}
而若我们想恢复贮藏后，仍在贮藏列表中保存，可以使用命令：git stash apply ，通用，也可以指定恢复贮藏：git stash apply stash@{制定编号}
我们继续进行开发，开发完成后进行提交：
我们可以看到，修复的 bug 内容并未在 dev3 上显示：
当前，master 分支的最新提交，领先于新建 dev3 分支时的提交，因此我们也就在 dev3 分支中看不到最新的修改
此时，我们需要让 master 合并 dev3 分支，若我们此时切回 master 分支并直接进行合并 ，此时可能会发生冲突，而代码的冲突需要我们手动进行解决，此时就是在 master上进行解决的，但是，若冲突问题比较复杂或比较多，我们就无法保证冲突问题可以正确地一次性解决掉，此时，就可能导致错误的代码被合并到 master上，从而导致 master 分支上出现 bug：
那么，该如何做呢？
我们可以在 dev3 分支上先合并 master 分支，若此时出现冲突，先在 dev3 分支上进行解决，让 dev3 分支保持最新，然后再让 master 合并 dev3 分支，从而不影响 master：
dev3 合并 master 分支，若合并时未发生冲突，会显示以下内容：
使用Ctrl + X即可退出：
此时，我们再切回 master 分支，合并 dev3 分支：
最后，再删除 dev3 分支：
删除临时分支
在开发过程中，当添加一个新功能时，我们都需要新建一个分支（被称为 feature 分支），在分支上进行开发，完成后，再进行合并，最后删除该分支
但是，若我们在某个 feature 分支上开发了一半，此时，被告知该功能废弃了，那么，这个分支也就误用了，需要进行销毁，若我们此时使用git branch -d 命令来进行删除：
Git 提示我们需要使用git branch -D命令来强制删除存在修改的分支：
