Git stash命令高级用法

先说说最基本的：默认只会暂存已跟踪文件的修改，但现实中我们常会遇到未跟踪的新文件。比如你新建了个，还没，直接stash的话，这文件就丢了。这时候可以用（或者），它能一并打包未跟踪文件。我有个同事就因此丢过配置，折腾了半天重写。更狠的是（），连忽略文件（比如里的）都收进来，适合清理现场用，不过得小心别把临时文件也存进去了。

另一个实用功能是给stash加备注。你肯定遇到过：stash了一堆东西，过几天回头看，满屏的、，根本分不清谁是谁。其实stash时可以带描述，比如，这样列表里一目了然。如果需要回顾某个stash的详情，用就能显示具体diff，比盲目apply安全多了。

apply和pop的区别很多人搞混。是应用完就删除stash，而只是应用，不删记录。我建议新手多用apply，尤其当stash内容复杂时——万一把分支搞乱了，还能回退。有一次我pop后才发现冲突没处理好，结果stash记录没了，只能手动回滚。如果非要用pop，可以先用测试，确认没问题再手动删除。

部分stash的技巧在团队协作里特别香。比如你同时改了UI组件和数据库逻辑，但只想暂存UI部分。可以先用把UI文件加到暂存区，然后，这样只stash工作区的改动，暂存区的保留着。之后你就能安心提交UI部分，再处理其他的。反过来，如果想从stash里恢复单个文件，可以用，直接提取指定文件，免去了全部覆盖的麻烦。

stash的清理也很讲究。是删除指定记录（比如），而是一锅端。我建议定期清理，不然stash列表越长越难管理。有个小窍门：用可以过滤出最近一周的stash，方便定位。如果是长期项目，可以写个脚本自动清理过期记录，比如用配合stash清理。

高级玩家还会用stash辅助rebase。比如你正在feature分支开发，突然要同步主支最新代码。如果直接rebase，未提交的改动可能引发冲突。这时可以先，然后，完成后再。这样能保持工作流干净，减少中间commit的干扰。不过注意，pop后如果有冲突，得手动解决——stash不会自动处理合并冲突。

最后提一个冷门场景：stash和钩子结合。比如在pre-commit钩子里，如果检测到代码不规范，可以自动stash改动，让用户修复后再pop回来。当然这需要定制脚本，但能大幅提升代码质量。总之，stash不是简单的“暂停键”，而是Git工作流里的瑞士军刀。多用多练，你也能像老司机一样，在分支间无缝切换。