Git，不要只拉不推，试试这五个命令，提高效率。
本文分享了我在开发工作中实践过的实用命令。这些可以大大提高工作效率，解决很多困难场景。下面将对命令进行介绍，列出应用场景，用于手触式教学，让学生看完就能学会。
官方解释:当你想记录工作目录和索引的当前状态，但又想返回一个干净的工作目录时，请使用git stash。该命令将保存本地修改并恢复工作目录以匹配提交的文件头。
Stash命令可以保存未提交的代码，并使您的工作目录干净。
我猜你一定在想:为什么要干净？
应用场景:有一天你正在特性分支开发新的需求，突然产品经理过来说线上有bug，必须马上修复。此时，您的函数已经开发了一半，所以您想匆忙切到主分支，然后您会看到以下错误:
因为目前有文件被更改，所以在拆分分支之前，您需要提交commit以保持工作区的整洁。因为情况紧急，要匆忙提交，提交信息也是用“临时代码”写的，所以分行提交记录留下了黑历史……(真人真事，我看过这个提交)
学了stash就不会这么尴尬了。你只需要:
就这么简单，代码就保存了。
当您修复了在线问题并切换回特性分支时，您只需要恢复代码:
当有多个存储时，您可以指定操作存储。首先，使用stash list列出所有记录:
应用第二条记录:
流行和下降是一样的。
隐藏代码
填备注，或者不填直接输入。
您可以在“贮藏”菜单中看到保存的贮藏。
首先单击stash记录旁边的小箭头，然后单击apply或pop以恢复stash。
根本不要接触索引文件或工作树(但在所有模式下都要将标题重置为)。这会将您所有更改的文件更改为“要提交的更改”。
回滚您提交的提交，并将提交的修改内容放回临时存储区域。
一般我们在使用reset命令的时候，会更多的提到git reset - hard，它可以强制提交记录追溯到某个节点。而git reset - soft的功能也是顾名思义。-Soft(软)不仅会回溯节点，还会保留节点的修改内容。
回溯节点，为什么要保留修改过的内容？
应用场景1:有时候不小心提交了不该提交的内容。这时候想改回来，只能再犯，再加一条“黑历史”。
应用场景二:标准化的团队一般要求提交的内容职责明确、粒度细，便于后续的问题调查。将两个具有不同功能的修改一起提交是不规则的。这一次，我的手又滑了一下，一次就犯了。
学习reset - soft后，您只需:
重置软相当于后悔药，给你一个改过自新的机会。对于上面的场景，您可以再次修改并重新提交以保持一个干净的提交记录。
上面是一个还没有被推送提交。也可以对已经推送的committed使用这个命令，但是再次推送的时候，因为远程分支和本地分支有区别，所以需要强行推送git push -f来覆盖reset committed。
还有一点需要注意的是，当reset - soft指定提交号时，从提交到最近一次提交的所有修改都将被恢复，而不仅仅是提交。
例如:
提交记录是c、b和a。
重置为a。
这时头部到了A，B和C的修改都回到了暂存区。
给定一个或多个现有提交，应用每个提交引入的更改，并为每个提交记录一个新的提交。这要求你的工作树是干净的(没有从头提交任何更改)。
复制提交的提交，并将新的提交应用到分支。
提交已提交，为什么需要复制新的？
应用场景1:有时候，版本的一些优化需求正在开发中，开发的某个需求可能会临时放上，或者要开发的需求因为某些原因卡在线上。这时候就需要把commit拿出来单独处理了。
应用场景2:有时开发分支中的代码记录被污染，导致开发分支合并到上线分支时出现问题。这时候就需要拉一个干净的开发分支，然后把commit从旧的开发分支复制到新的分支。
复制单个
现在有一个功能分支，提交记录如下:
你需要把B复制到另一个分支，先复制commitHash，然后切到master分支。
当前主节点的最新记录是a。使用cherry-pick将B应用于当前分支。
完成后看最新日志。b已作为最新提交应用于主服务器。可以看到commitHash和之前的不一样，但是提交时间还是之前的。微信搜索微信官方账号:java后端编程，回复:Java获取信息。
重复倍数
以上是单次提交的副本。让我们来看看如何挑选多个提交操作。
上述命令将commit1和commit2应用于当前分支。
上述命令将commit1到commit2范围内的所有提交应用到当前分支(包括commit1和commit2)，commit1是最早的提交。
当cherry-pick有多个提交时，可能会遇到代码冲突，然后cherry-pick会停止，让用户决定如何进行。让我们看看如何解决这种情况。
仍然是特征分支，现在需要把C、D、E复制到主分支。先写下起点c和终点e的commitHash。
切到主枝，用中间的樱桃核。可以看到C复制成功。到D的时候发现代码冲突，cherry-pick中断。这时需要解决代码冲突，重新提交到临时存储区。
然后使用cherry-pick - continue让cherry-pick继续。最后把e复制进去，整个过程就完成了。
以上是一个完整的过程，但有时可能需要在代码冲突后放弃或退出该过程:
回到手术前的样子，若无其事。
不要回到手术前的样子。也就是说，保留已经成功挑选的提交，并退出挑选过程。
给定一个或多个现有提交，恢复由相关提交引入的更改，并记录这些更改的一些新提交。这要求你的工作树是干净的(从头开始没有变化)。
还原已有提交，还原已提交的内容，生成还原记录。
应用场景:某天测试突然告诉你，你在网上开发的功能有问题，需要你马上撤销，否则会影响系统的使用。这时候你可能会想到用reset回滚，但是你看分支上的最新提交和其他同事的代码，用reset也会撤回这部分代码。因为情况紧急，又想不出好办法，你还是任性的用reset，然后让同事再结合他的代码(同事一听就想打人)，所以你的技术形象在同事眼中一落千丈。
回复普通提交
学会revert后，可以立刻挽回这种尴尬的局面。
现在主记录如下:
Revert放弃他自己提交的提交。
因为revert将生成新的提交记录，所以此时会要求您编辑提交信息。编辑完成后，wq会保存并退出。
让我们看看最新的日志，并生成一个恢复记录。虽然您之前的提交记录仍会保留，但您修改的代码内容已被撤回。
在git的提交记录中，还有另一种类型的合并提交。如果您想要恢复到合并提交，使用起来会有些不同。
现在主分支中有一个合并提交。
使用刚才相同的revert方法，您会发现命令行报告了一个错误。为什么会这样？在官方文件中有解释。
通常无法还原合并，因为你不知道合并的哪一方应该被视为主线。此选项指定主线的父编号(从1开始),并允许revert反转相对于指定父编号的更改。
我的理解是，合并提交是两个分支的交集，git不知道需要撤销哪个分支。它需要添加参数-m来指定主分支，保留主分支的代码，另一个分支将被撤销。
-m后面应该跟一个母号来标识“主线”。一般用1预留主支行代码。
还是上面的场景，主分支revert合并提交后，然后在feature分支中修复bug，再合并到主分支中，你会发现之前revert修改的内容并没有再次合并。
因为在使用revert之后，特性分支的提交仍然会保留在主分支的记录中。当您再次合并它时，git判断有相同的commitHash，并忽略相关提交的修改内容。
这时候就需要先还原合并提交再还原，有点尴尬。接下来我们来看操作。
现在大师的战绩是这样的。
如果您再次使用revert，以前通过revert修改的内容将会恢复。
该命令管理重录中记录的信息。
如果说reset - soft是后悔药，那么reflog就是强效后悔药。它记录了所有的提交操作记录，方便在错误操作后检索记录。
应用场景:有一天，你眼花缭乱，发现自己已经在别人的分支里提交了代码，推送到远程分支。这时候因为分支只有你最新提交的，你就想着用reset - hard，结果不小心记错了commitHash，重置太多，同事的commit丢失了。没办法，reset - hard被逼退，找不到commitHash，只能让同事从本地分公司再推一次(同事拳头瞬间硬了，又是你)。结果你的技术形象一落千丈。
分支记录如上，你想重置为b。
复位误操作太多，B没了，最新的只有a。
此时，使用git reflog检查历史记录，并记下提交错误的commitHash。
再次重置，你会发现B又回来了。
对于我这个喜欢输入命令而不是图形工具的粉丝来说，设置短命令可以提高效率。以下是设置短命令的两种方法。
打开全局配置文件
写内容
本文主要分享五个在开发中比较实用的Git命令，以及设置短命令的方法。
文中列举的一些应用场景并不恰当，只是为了便于学生理解。最重要的是明白命令是什么，这样学习和使用才能发挥最大的效果。
好了，今天的分享就到这里。下次见~