随着公司开发人员的增加,以及多需求的并行开发,功能上线就会碍手碍脚;害怕自己没写完的代码被别人部署到线上,害怕别人代码没写完被自己部署到线上;总之功能上线之前还要和所有开发沟通,能不能部署代码?如果只是几个人的团队倒也无妨,但是开发人员多了,沟通成本就很高了。于是 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 利用好了,就可以自如切换分支,面对突如其来的需求也不必烦恼了~