随着公司开发人员的增加，以及多需求的并行开发，功能上线就会碍手碍脚；害怕自己没写完的代码被别人部署到线上，害怕别人代码没写完被自己部署到线上；总之功能上线之前还要和所有开发沟通，能不能部署代码？如果只是几个人的团队倒也无妨，但是开发人员多了，沟通成本就很高了。于是 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 利用好了，就可以自如切换分支，面对突如其来的需求也不必烦恼了~
到此这篇关于IDEA Git Stash 使用详解的文章就介绍到这了,更多相关IDEA Git Stash 使用内容请搜索脚本之家以前的文章或继续浏览下面的相关文章希望大家以后多多支持脚本之家！