Git 不能只会 pull 和 push，试试这5条提高效率的命令吧！（一）

• 前言
• stash
• reset --soft
• cherry-pick

前言

使用 Git 作为代码版本管理，早已是现在开发工程师必备的技能。可大多数工程师还是只会最基本的保存、拉取、推送，遇到一些commit管理的问题就束手无策，或者用一些不优雅的方式解决。

本文分享我在开发工作中实践过的实用命令。这些都能够大大提高工作效率，还能解决不少疑难场景。下面会介绍命令，列出应用场景，手摸手教学使用，让同学们看完即学会。

基于 Spring Boot + MyBatis Plus + Vue & Element 实现的后台管理系统 + 用户小程序，支持 RBAC 动态权限、多租户、数据权限、工作流、三方登录、支付、短信、商城等功能。

项目地址：https://github.com/YunaiV/ruoyi-vue-pro

stash

描述

官方解释：当您想记录工作目录和索引的当前状态，但又想返回一个干净的工作目录时，请使用git stash。该命令将保存本地修改，并恢复工作目录以匹配头部提交。

stash 命令能够将还未 commit 的代码存起来，让你的工作目录变得干净。

应用场景

我猜你心里一定在想：为什么要变干净？

应用场景：某一天你正在 feature 分支开发新需求，突然产品经理跑过来说线上有bug，必须马上修复。而此时你的功能开发到一半，于是你急忙想切到 master 分支，然后你就会看到以下报错：

因为当前有文件更改了，需要提交commit保持工作区干净才能切分支。由于情况紧急，你只有急忙 commit 上去，commit 信息也随便写了个“暂存代码”，于是该分支提交记录就留了一条黑历史…(真人真事，看过这种提交)

命令使用

如果你学会 stash，就不用那么狼狈了。你只需要：

git stash

就这么简单，代码就被存起来了。

当你修复完线上问题，切回 feature 分支，想恢复代码也只需要：

git stash apply

相关命令

> 基于微服务的思想，构建在 B2C 电商场景下的项目实战。核心技术栈，是 Spring Boot + Dubbo 。未来，会重构成 Spring Cloud Alibaba 。
>
> 项目地址：<https://github.com/YunaiV/onemall>
# 保存当前未commit的代码  
git stash  
# 保存当前未commit的代码并添加备注  
git stash save "备注的内容"  
# 列出stash的所有记录  
git stash list  
# 删除stash的所有记录  
git stash clear  
# 应用最近一次的stash  
git stash apply  
# 应用最近一次的stash，随后删除该记录  
git stash pop  
# 删除最近的一次stash  
git stash drop

当有多条 stash，可以指定操作stash，首先使用stash list 列出所有记录：

$ git stash list  
stash@{0}: WIP on ...  
stash@{1}: WIP on ...  
stash@{2}: On ...

应用第二条记录：

$ git stash apply stash@{1}

pop，drop 同理。

vscode 集成

stash 代码

填写备注内容，也可以不填直接Enter

在STASHES菜单中可以看到保存的stash

先点击stash记录旁的小箭头，再点击 apply 或者 pop 都可恢复 stash

reset --soft

描述

完全不接触索引文件或工作树（但会像所有模式一样，将头部重置为）。这使您的所有更改的文件更改为“要提交的更改”。

回退你已提交的 commit，并将 commit 的修改内容放回到暂存区。

一般我们在使用 reset 命令时，git reset --hard会被提及的比较多，它能让 commit 记录强制回溯到某一个节点。而git reset --soft的作用正如其名，--soft(柔软的) 除了回溯节点外，还会保留节点的修改内容。

应用场景

回溯节点，为什么要保留修改内容？

应用场景1：有时候手滑不小心把不该提交的内容 commit 了，这时想改回来，只能再 commit 一次，又多一条“黑历史”。

应用场景2：规范些的团队，一般对于 commit 的内容要求职责明确，颗粒度要细，便于后续出现问题排查。本来属于两块不同功能的修改，一起 commit 上去，这种就属于不规范。这次恰好又手滑了，一次性 commit 上去。

命令使用

学会reset --soft之后，你只需要：

# 恢复最近一次 commit  
git reset --soft HEAD^

reset --soft相当于后悔药，给你重新改过的机会。对于上面的场景，就可以再次修改重新提交，保持干净的 commit 记录。

以上说的是还未 push 的commit。对于已经 push 的 commit，也可以使用该命令，不过再次 push 时，由于远程分支和本地分支有差异，需要强制推送git push -f来覆盖被 reset 的 commit。

还有一点需要注意，在reset --soft指定 commit 号时，会将该 commit 到最近一次 commit 的所有修改内容全部恢复，而不是只针对该 commit。

举个例子：

commit 记录有 c、b、a。

reset 到 a。

git reset --soft 1a900ac29eba73ce817bf959f82ffcb0bfa38f75

此时的 HEAD 到了 a，而 b、c 的修改内容都回到了暂存区。

cherry-pick

描述

给定一个或多个现有提交，应用每个提交引入的更改，为每个提交记录一个新的提交。这需要您的工作树清洁（没有从头提交的修改）。

将已经提交的 commit，复制出新的 commit 应用到分支里

应用场景

commit 都提交了，为什么还要复制新的出来？

应用场景1：有时候版本的一些优化需求开发到一半，可能其中某一个开发完的需求要临时上，或者某些原因导致待开发的需求卡住了已开发完成的需求上线。这时候就需要把 commit 抽出来，单独处理。

应用场景2：有时候开发分支中的代码记录被污染了，导致开发分支合到线上分支有问题，这时就需要拉一条干净的开发分支，再从旧的开发分支中，把 commit 复制到新分支。

命令使用

复制单个

现在有一条feature分支，commit 记录如下：

需要把 b 复制到另一个分支，首先把 commitHash 复制下来，然后切到 master 分支。

当前 master 最新的记录是 a，使用cherry-pick把 b 应用到当前分支。

完成后看下最新的 log，b 已经应用到 master，作为最新的 commit 了。可以看到 commitHash 和之前的不一样，但是提交时间还是保留之前的。

复制多个

以上是单个 commit 的复制，下面再来看看 cherry-pick 多个 commit 要如何操作。

• 一次转移多个提交：

git cherry-pick commit1 commit2

上面的命令将 commit1 和 commit2 两个提交应用到当前分支。

• 多个连续的commit，也可区间复制：

git cherry-pick commit1^..commit2

上面的命令将 commit1 到 commit2 这个区间的 commit 都应用到当前分支（包含commit1、commit2），commit1 是最早的提交。

cherry-pick 代码冲突

在cherry-pick多个commit时，可能会遇到代码冲突，这时cherry-pick会停下来，让用户决定如何继续操作。下面看看怎么解决这种场景。

还是 feature 分支，现在需要把 c、d、e 都复制到 master 分支上。先把起点c和终点e的 commitHash 记下来。

切到 master 分支，使用区间的cherry-pick。可以看到 c 被成功复制，当进行到 d 时，发现代码冲突，cherry-pick中断了。这时需要解决代码冲突，重新提交到暂存区。

然后使用cherry-pick --continue让cherry-pick继续进行下去。最后 e 也被复制进来，整个流程就完成了。

以上是完整的流程，但有时候可能需要在代码冲突后，放弃或者退出流程：

• 放弃 cherry-pick：

git cherry-pick --abort

回到操作前的样子，就像什么都没发生过。

• 退出 cherry-pick：

git cherry-pick --quit

不回到操作前的样子。即保留已经cherry-pick成功的 commit，并退出cherry-pick流程。