Git 不要只会 pull 和 push，试试这 5 条提高效率的命令

序言

采用 Git 作为标识符版管理工作，已然是现在合作开发技师必不可少的专业技能。可绝大多数技师还是只会最基本的留存、拉取、发送，碰到许多commit管理工作的问题就无能为力，或是用许多不典雅的方式化解。

责任编辑撷取我在开发组织工作中课堂教学过的新颖指示。这些都能大大降低组织管理效率，还能化解许多疑难杂症情景。上面会如是说指示，列举应用领域情景，嘴巴手课堂教学采用，让全校师生看完即专业委员会。

stash

非官方说明：当您想历史记录组织工作产品目录和检索的现阶段状况，但又想回到一个整洁的组织工作产品目录时，请采用git stash。该指示将留存邻近地区修正，并恢复正常组织工作产品目录以相匹配颈部递交。

stash 指示能将还未 commit 的标识符存出来，让你的组织工作产品目录显得整洁。

我猜你心中一定在想：为何蔗茅整洁？

应用领域情景：某一天你正在 feature 组成部分合作升级换代市场需求，忽然产品副经理二话不说说线上有bug，必须立刻复原。而这时你的机能合作开发到三分之一，只好你连忙想切到 master 分支，然后你就会看到下列收起：

因为现阶段有文档更动了，须要递交commit保持组织工作区整洁就可以切组成部分。由于莱盖，你只有连忙 commit 上来，commit 重要信息也就行了写了个“存贮标识符”，只好该组成部分递交历史记录就留了两条黑历史…(Dhanbad，看完这种递交)

如果你专业委员会 stash，就不必那么惊慌失措了。你只须要：

 stash

就这么单纯，标识符就被存出来了。

当你复原完线上问题，切回 feature 组成部分，想恢复正常标识符也只须要：

 stash apply

 stash

git stash list

git stash clear

git stash apply

git stash pop

git stash drop

当有多条 stash，可以指定操作stash，首先采用stash list 列举所有历史记录：

$ git stash list

应用领域第二条历史记录：

$ git stash apply stash@{1}

pop，drop 同理。

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之后，你只须要：

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。

这时的 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 要如何操作。

一次转移多个递交：

 cherry-pick commit1 commit2

上面的指示将 commit1 和 commit2 两个递交应用领域到现阶段组成部分。

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

上面的指示将 commit1 到 commit2 这个区间的 commit 都应用领域到现阶段组成部分（包含commit1、commit2），commit1 是最早的递交。

在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：

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

退出 cherry-pick：

cherry-pick –quit

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

revert

给定一个或多个现有递交，恢复正常相关递交引入的更动，并历史记录一些这些更动的新递交。这就要求你的组织工作树是整洁的（没有来自颈部的修正）。

将现有的递交还原，恢复正常递交的内容，并生成两条还原历史记录。

应用领域情景：有一天测试忽然跟你说，你合作开发上线的机能有问题，须要立刻撤回，否则会影响到系统采用。这时可能会想到用 reset 回退，可是你看了看组成部分上最新的递交还有其他同事的标识符，用 reset 会把这部分标识符也撤回了。由于莱盖，又想不到好方法，还是任性的采用 reset，然后再让同事把他的标识符合一遍（同事听到想打人），只好你的技术形象在同事眼里一落千丈。

revert 普通递交

专业委员会 revert 之后，立马就可以拯救这种尴尬的情况。

现在 master 历史记录如下：

 revert 21dcd937fe555f58841b17466a99118deb489212

revert 掉自己递交的 commit。

因为 revert 会生成两条新的递交历史记录，这时会让你编辑递交重要信息，编辑完后 :wq 留存退出就好了。

再来看下最新的 log，生成了两条 revert 历史记录，虽然自己之前的递交历史记录还是会保留着，但你修正的标识符内容已经被撤回了。

在 git 的 commit 历史记录里，还有一种类型是合并递交，想要 revert 合并递交，采用上会有些不一样。

现在的 master 组成部分里多了条合并递交。

采用刚刚同样的 revert 方法，会发现指示行收起了。

通常无法 revert 合并，因为您不知道合并的哪一侧应被视为主线。此选项指定主线的父编号（从1开始），并允许 revert 反转相对于指定父编号的更动

我的理解是因为合并递交是两条组成部分的交集节点，而 git 不知道须要撤销的哪两条组成部分，须要添加参数 -m 指定主线组成部分，保留主线组成部分的标识符，另两条则被撤销。

-m 后面要跟一个 parent number 标识出”主线”，一般采用 1 保留主组成部分标识符。

还是上面的情景，在 master 组成部分 revert 合并提交后，然后切到 feature 组成部分复原好 bug，再合并到 master 组成部分时，会发现之前被 revert 的修正内容没有重新合并进来。

因为采用 revert 后， feature 组成部分的 commit 还是会保留在 master 组成部分的历史记录中，当你再次合并进去时，git 判断有相同的 commitHash，就忽略了相关 commit 修正的内容。

这时就须要 revert 掉之前 revert 的合并递交，有点拗口，接下来看操作吧。

现在 master 的历史记录是这样的。

再次采用 revert，之前被 revert 的修正内容就又回来了。

reflog

此指示管理工作重录中历史记录的重要信息。

如果说reset –soft是后悔药，那 reflog 就是强力后悔药。它历史记录了所有的 commit 操作历史记录，便于错误操作后找回历史记录。

应用领域情景：某天你眼花，发现自己在其他人组成部分递交了标识符还推到远程组成部分，这时因为组成部分只有你的最新递交，就想着采用reset –hard，结果紧张不小心记错了 commitHash，reset 过头，把同事的 commit 搞没了。没办法，reset –hard是强制回退的，找不到 commitHash 了，只能让同事从邻近地区组成部分再推一次（同事瞬间拳头就硬了，怎么又是你）。只好，你的技术形象又一落千丈。

组成部分历史记录如上，想要 reset 到 b。

误操作 reset 过头，b 没了，最新的只剩下 a。

这时用git reflog查看历史历史记录，把错误递交的那次 commitHash 记下。

再次 reset 回去，就会发现 b 回来了。

设置 Git 短指示

对我这种喜欢敲指示而不必图形化工具的爱好者来说，设置短指示可以很好的降低成本。上面如是说两种设置短指示的方式。

.ps push

打开全局配置文档

~/.gitconfig

写入内容

[alias] 

        co = checkout

        pl = pull

-ff

        cp = cherry-pick

总结

责任编辑主要撷取了5个在合作开发中新颖的 Git 指示和设置短指示的方式。

stash：存储临时标识符。

reset –soft：软回溯，回退 commit 的同时保留修正内容。

cherry-pick：复制 commit。

revert：撤销 commit 的修正内容。

reflog：历史记录了 commit 的历史操作。

文中列举的应用领域情景有部分不太恰当，只是想便于全校师生理解，最重要的是要理解指示的作用是什么，活学活用就可以发挥最大功效。

如果你也有许多新颖的 Git 指示也欢迎在评论区撷取~

作者：出来吧皮卡丘