随着公司开发人员的增加，以及多需求的并行开发，功能上线就会碍手碍脚；害怕自己没写完的代码被别人部署到线上，害怕别人代码没写完被自己部署到线上；总之功能上线之前还要和所有开发沟通，能不能部署代码？如果只是几个人的团队倒也无妨，但是开发人员多了，沟通成本就很高了。于是 Git 的分支就发挥它的作用了，本文讲解工作中使用 IDEA 进行分支的管理以及合并，以及其他 Git 使用技巧。
环境准备
为了演示，先用 IDEA 创建一个简单工程，提交到 git 远程仓库当中。
dev-100 分支创建
现在接到了一个编号为 100 的需求，我们在 master 基础上，创建 dev-100 分支
创建新分支 dev-100的同时，并切换到 dev-100 分支。
dev-100 分支代码开发
在 dev-100 分支编写需求编号为 100 的 功能，代码完成后进行 commit 以及 push（如果这个分支只有你一个人在开发的话，就不用 push 到远程分支了，只需要 commit 即可）
分支合并
现在我们要把 dev-100 分支上的代码合并到 master 主分支上
先切换到 master 分支
合并 dev-100 分支到 master 分支之前，建议先对 master 代码进行 pull 更新操作，然后再执行 Merge into Current
如果没有冲突，dev-100 中的代码就会被合并到 master 分支上了，合并成功后，需要 push 才能推送到远程仓库
取消分支合并
合并完成后，但是由于一些问题，我们想要取消本次合并，右键 git，选择 Reset HEAD
HEAD^ 是还原到上一个版本，HEAD^^ 是还原到上上一个版本。
Reset Type 有三种：
- mixed 默认方式，只保留源码，回退commit和index信息
- soft 回退到某个版本，只回退了commit的信息，不会恢复到index file一级。如果还要提交，直接commit
- hard 彻底回退，本地源码也会变成上一个版本内容
一般使用默认的 mixed 或者粗暴的 hard 方式。
我们这里是取消合并，所以选择 Hard 方式，并且是HEAD^还原到上一个版本，回退后恢复了原来 master 的代码。
解决合并冲突问题
接下来演示合并冲突，此时是在 master 分支，我们修改文件，并 commit 以及 push 到远程仓库。
此时再把 dev-100 分支合并到 master 分支就会提示冲突。
双击冲突文件，处理冲突。
处理完成后，点击 apply 即可，如果有多个冲突文件，都按照这种方式处理，这是我们处理完冲突之后的代码。
dev-100 分支已经被成功合并到 master 了，就可以删除了。可以直接删除远程 dev-100 分支，删除时 IDEA 会提示是否同时删除本地的 dev-100 分支，勾选即可。
现在我们把分支合并的结果 push 到远程仓库。
代码暂存之git stash
编号 100 的需求完成之后，现在我们又接到一个新的需求，正在 dev-101 分支进行开发，开发还未完成。
突然线上出现 bug，需要我们紧急进行修改，于是我们要基于最新的 master 分支新建一个 bug 分支 bug-12，需要先切换到 master 分支，但是当前分支的代码没有commit， 如果直接切换到 master 分支的话，dev-101 分支上的新增代码就会跑到 master 分支，而代码又不能此时 commit ，于是就轮到 stash 出场了。
Stash 会保存当前工作进度，会把暂存区和工作区的改动保存起来。
添加备注，选择 CREATE STASH。你会发现当前工作区内的代码被恢复成了原样。
代码暂存还原
此刻切换到 master 分支，并创建 bug-12 分支进行修复 bug，修复完成后合并到 master 分支并 push 到远程仓库，上文已经演示如何合并，在此不再赘述。
将 bug-12 与 master 合并完成之后，现在要接着写 dev-101 需求代码，首先先切换到 dev-101 分支；
但是之前的代码已经被我们放到了 git 的 stash 当中，我们现在要把代码还原到工作区当中。
选择 Unstash Changes
选择之前保存的，同时勾选 Pop stash（还原完成后，会自动删除这个 stash），确定后，工作区之前写的代码就又回来了。
结语
Stash 利用好了，就可以自如切换分支，面对突如其来的需求也不必烦恼了~