shelve changes VS stash changes
在写代码的过程中,有时候一些代码不需要在当前版本commit或者当害怕本地代码和远程有冲突时,我们可以先搁置代码,然后再手动解决冲突、
idea为我们提供了git shelve changes功能,而git也给我们提供了stash changes这个工具,那这两者有啥区别?
代码不需要commit时:
我们在工程中新增一个文件:

stash changes
此时,当前版本中并不需要commit该文件,我们可以用stash changes命令来搁置该文件:

点击后,出现下方操作框,因为keep index 会产生无用的git log,所以,我们不勾选keep index:

点击后,该文件就不出现在工作区了,commit时如下:

我们用unstash changes恢复原状:

点击后,出现如图所示,如果确认该被搁置的文件之后无需重新搁置,勾选pop stash,则该stash会被删除:

此处默认不勾选,我们直接apply stash:

文件恢复并有成功提示字样。
shelve changes
如果我们选择的是shelve changes呢?
同样的菜单栏入口:

我们选择后,出现这个界面:

填入commit message 然后 shelve changes,再看看工作区:

我们来commit试试,点击工具栏上的commit按钮,再点击shelve,发现其中出现了我们刚刚搁置的文件:

我们进行unshelve,在该shelve上右键:

选择unshelve后,出现:

其中set active和track context以及最下面的remove默认不勾选,我们勾选set active和track context后,点击unshelve changes,看看:

该shelve还在,并且出现提示消息,我们点击左边commit to dev页签,发现:

多了一个changlist,并且该commit message和我们刚才输入的一致,我们进行修改,然后commit:

再次查看git log:

该changelist并不会被删除,只是其中没有了文件。
防止冲突时
当我们在本地commit的代码有问题,需要git reset时,为了防止reset后,出现update reject的情况,我们可以在reset代码后,先搁置代码,然后再释放代码,手动进行合并。
我们来模拟一下,首先,远程commit两次:

这里我update了GitDemo和GitMini两个类,然后,我们本地在同样的位置进行更新:

然后再更新一个文件:

三次commit之后,发现本地有多余的文件,于是我们先进行代码回退:

shelve changes
在进行update project前,为了防止冲突,我们先搁置代码:

搁置后:

commit中多了一个changelist:

然后,我们update project:

可以看到,远程中有两个文件更新了,我们对本地搁置的代码进行释放,勾选remove,以用来删除已经合并成功的文件:

解决完冲突后:

shelve不见了,进行commit时,发现该changelist移动到了default changelist下:

stash changes
刚才用了shelve changes,现在我们用stash changes来试试:

同样是三个文件:

然后,update project:

再之后,我们pop stash:

解决完冲突后,我们进行commit:

可以发现,要commit的文件还是位于default changelist下,并不会有多余的commit列表。
区别
经过上面的两个案例,我们发现,两者的区别有:
1、 shelve changes 是idea自带的,会生成default changelist,并且要commmit的文件会放在该changelist下;
2、stash changes 不会生成changelist,如果需要删除需要勾选pop命令行;
3、shelve changes即使勾选了remove successfully applied files from the shelf 后,虽然不会再在shelf页签显示,但仍然会在commit to dev页签下的default changelist下生成多余的列表信息,必须手动进行删除。
本文对比了IDEA中的shelvechanges与git的stashchanges功能。前者为IDEA特有,用于创建变更列表,后者则直接操作git仓库,两者均可在无需提交时暂存更改,避免合并冲突。
1427





