开发工作中实践过的实用命令——大大提高工作效率

前言

使用 Git 作为代码版本管理长期以来一直是当今开发工程师的必备技能。但是大部分工程师还是只存、拉、推最基础的，遇到一些commit管理问题时束手无策，或者用一些不雅的方式解决。

本文分享了我在开发工作中实践过的有用命令。这些可以大大提高工作效率，解决很多困难的场景。下面将对命令进行介绍，列举应用场景，并进行手把手教学和使用，让同学们看完后学有所成。

爱你

藏

描述

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

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

stash 命令保存未提交的代码以保持工作目录干净。

应用场景

我想你一定在想：为什么要干净？

应用场景：有一天你在特性分支开发新的需求，突然产品经理跑过来说有bug上线了，必须马上修复。至此，你的功能开发到一半了，急着切换到master分支，然后会看到如下错误：

由于当前有文件更改，因此您需要在分支之前提交提交以保持工作空间清洁。由于紧急，只得赶紧commit起来，而且commit信息还写了一个“临时代码”，所以分支提交记录留下了黑历史……（真人，我见过这种提交）

命令用法

如果你学会了藏匿，你就不必那么尴尬了。您只需：

混帐藏匿

复制代码

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

修复在线问题后，切换回功能分支并恢复代码，只需：

git 存储应用

复制代码

相关命令

# 保存当前未提交的代码

混帐藏匿

# 保存当前未提交的代码并添加注释

git stash 保存“笔记的内容”

# 列出所有的stash记录

git 存储列表

# 删除所有stash记录

git 存储清除

# 应用最近的存储

git 存储应用

# 应用最近的存储，然后删除记录

git stash 弹出

# 删除最近的存储

git 存储下降

复制代码

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

$ git 存储列表

stash@{0}：WIP 上…

stash@{1}：WIP 上…

stash@{2}：开…

复制代码

应用第二条记录：

$ git stash apply stash@{1}

复制代码

pop 和 drop 也是如此。

vscode 集成

存储代码

填写备注，也可以留空直接输入

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

先点击stash记录旁边的小箭头，然后点击apply或者pop来恢复stash

重置–软

描述

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

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

回滚您提交的提交并将提交的更改放回暂存区域。

一般我们在使用reset命令的时候，会多提到git reset\–hard，它可以强制commit记录回溯到某个节点。而 git reset \–soft 正是顾名思义，–soft（软）除了回溯之外，还会保留节点的修改内容。

应用场景

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

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

应用场景二：标准化团队一般对commit的内容有明确的职责和细粒度的要求，方便后续排查。本来属于两个不同功能的修改，一起commit，不规范。这一次，我只是再次失手并进行了一次性提交。

命令用法

学会重置\–soft后，只需要：

# 恢复上一次提交

git reset –soft HEAD^

复制代码

reset \–soft相当于后悔药，给你一次重新改变的机会。对于上述场景，您可以修改并重新提交以保持干净的提交记录。

以上是尚未推送的提交。该命令也可以用于已经推送的commit，但是再次推送的时候，由于远程分支和本地分支的差异，需要强制push git push \-f 覆盖reset commit。

还有一点需要注意的是，reset \–soft 指定commit number 时，从commit 到最后一次commit 的所有修改都会被恢复，而不仅仅是commit。

举个栗子：

提交记录有 c、b 和 a。

重置为 a。

git reset –soft 1a900ac29eba73ce817bf959f82ffcb0bfa38f75

复制代码

此时HEAD已经到了a，b和c的修改内容已经全部返回到暂存区。

樱桃采摘

描述

给定一个或多个现有提交，应用每个提交引入的更改，并为每个提交记录一个新提交。这要求您的工作树是干净的（没有从头开始提交的修订）。

给定一个或多个现有提交，应用每个提交引入的更改，并为每个提交记录一个新提交。这要求您的工作树是干净的（没有从头开始提交的修订）。

复制已经提交的commit，复制新的commit并应用到分支

应用场景

提交都提交了，为什么要复制新的？

应用场景一：有时版本的一些优化需求开发了一半，可能临时添加了其中一个开发需求，或者由于某些原因，待开发需求卡住了，完成需求上线。这时候，commit 需要单独提取和处理。

应用场景二：有时开发分支中的代码记录被污染，导致开发分支合并到在线分支出现问题。在这种情况下，需要拉出一个干净的开发分支git命令行拉取代码，然后将提交从旧的开发分支复制到新的分支。

用于复制单个的命令

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

需要将b复制到另一个分支，先复制commitHashgit命令行拉取代码，然后切换到master分支。

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

完成后查看最新的日志，b已经应用到master上，作为最新的commit。可以看到commitHash和之前的不一样了，但是commit时间还是和之前一样。

复制多个

以上是单个commit的replication，我们来看看cherry-pick多个commit是如何操作的。

一次传输多个提交：

git 樱桃选择 commit1 commit2

复制代码

上述命令将两个提交 commit1 和 commit2 应用于当前分支。

多个连续提交也可以间隔复制：

git cherry-pick commit1^..commit2

复制代码

上述命令将commit1到commit2的提交应用到当前分支（包括commit1、commit2），commit1是最早的commit。

挑选代码冲突

当cherry-pick 提交多个提交时，可能会遇到代码冲突。这时，cherry-pick 将停止，让用户决定如何进行。让我们看看如何解决这种情况。

它仍然是一个特性分支，现在需要将 c、d 和 e 复制到 master 分支。首先记下起点c和终点e的commitHash。

切换到 master 分支并使用范围 cherry-pick。可以看到c复制成功，到d的时候发现代码冲突，cherry-pick中断。这时候需要解决代码冲突，重新提交到暂存区。

然后使用cherry-pick \–continue 使cherry-pick 继续。最后把e也拷贝进去，整个过程就完成了。

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

gits cherry-pick –abort

复制代码

回到手术前的样子，仿佛什么都没发生过一样。

git cherry-pick –quit

复制代码

不要恢复到手术前的状态。也就是保留已经被cherry-pick成功的commit，退出cherry-pick过程。

恢复

描述

给定一个或多个现有提交，还原相关提交引入的更改，并记录一些带有这些更改的新提交。这要求您的工作树是干净的（头部没有修改）。

给定一个或多个现有提交，还原相关提交引入的更改，并记录一些带有这些更改的新提交。这要求您的工作树是干净的（头部没有修改）。

还原现有提交，还原已提交的内容，并生成还原记录。

应用场景

应用场景：某天测试突然告诉你，你开发上线的功能有问题，需要立即撤回，否则会影响系统的使用。这个时候你可能会想到用reset回去，但是如果你看一下分支上的最新commit和其他同事的代码，用reset也会撤回这部分代码。因为情况紧急，想不出好办法，还是乱用reset，然后让同事重新组合他的代码（同事听说要打人），所以你的技术形象在眼里一落千丈的同事。

使用恢复正常提交的命令

学会还原后，就可以立马挽救这个尴尬的局面。

现在主记录如下：

还原自己提交的提交。

因为revert会生成一个新的提交记录，那么你会被要求编辑提交信息。编辑后：wq保存退出。

让我们看一下最新的日志并生成还原记录。虽然还是会保留之前的提交记录，但是你修改的代码内容已经被撤回了。

还原合并提交

在 git 的提交记录中，还有另一种类型的合并提交。如果要还原合并提交，用法会略有不同。

master 分支中现在有更多的合并提交。

使用刚才相同的revert方法，你会发现命令行报错。

为什么会这样？官方文档中对此进行了解释。

通常不可能恢复合并，因为您不知道合并的哪一侧应该被视为主线。此选项指定主线的父编号（从 1 开始）并允许还原以反转相对于指定父编号的更改

通常不可能恢复合并，因为您不知道合并的哪一侧应该被视为主线。此选项指定主线的父编号（从 1 开始）并允许还原以反转相对于指定父编号的更改

我的理解是merge commit是两个分支的交集，git不知道需要撤销哪个分支。需要加参数-m来指定主线分支，保留主线分支的代码，另外一个撤销。

-m 后面应该跟一个父编号来标识“主线”，一般用1来保留主分支代码。

git 还原 -m 1

复制代码

revert merge commit 后，再次合并分支会失效

上述场景中，master分支revert合并提交后，再切换到feature分支修复bug，再merge到master分支，你会发现之前revert的修改并没有被remerged进去。

因为使用revert之后，feature分支的commit仍然会保存在master分支的记录中。再次合并时，git判断有相同的commitHash，而忽略相关commit修改的内容。

这时候需要revert之前revert的merge commit，有点尴尬。接下来看看操作。

现在主记录是这样的。

再次使用revert，之前revert的修改内容又回来了。

引用日志

描述

该命令管理重新记录中记录的信息。

该命令管理重新记录中记录的信息。

如果 reset \–soft 是后悔药，那么 reflog 是强后悔药。记录所有的提交操作记录，方便错误操作后检索记录。

应用场景

应用场景：某天你眼花缭乱，发现自己在别人的分支提交了代码，然后推送到了远程分支。这时候因为分支只有你最近提交的，你想用reset \–hard，不小心记错了。commitHash，reset过多，同事的commit丢失。没办法，reset \–hard是强制回滚，commitHash找不到，同事只能从本地分支再push一次（同事的拳头瞬间硬了，怎么又是你）。结果，你的技术形象一落千丈。

命令用法

分支记录如上，我想重置为b。

误操作reset太远，b没了，最后只剩下a了。

这时候，使用git reflog查看历史，记下错误提交的commitHash。

如果再重新设置，你会发现b又回来了。

设置 Git 短命令

对于像我这样喜欢键入命令而不是图形工具的爱好者来说，设置短命令可能非常有效。下面介绍两种设置短命令的方法。

方法一

git config –global alias.ps 推送

复制代码

方法二

打开全局配置文件

vim ~/.gitconfig

复制代码

写内容

[别名]

co = 结帐

ps = 推

pl = 拉

mer = 合并 –no-ff

cp = 樱桃采摘

复制代码

采用

# 等价于 git cherry-pick

git cp

复制代码

总结

本文主要分享5个开发中实用的Git命令以及如何设置短命令。

stash ：存储临时代码。

reset –soft ：软回溯，在保留修改内容的同时恢复提交。

cherry-pick ：复制提交。

revert ：撤消提交的修改。

reflog ：记录commit的历史操作。

文中列举的一些应用场景有些不妥，但我只是想让同学们更容易理解。最重要的是要了解命令的功能是什么。只有学习和应用，才能发挥最大的作用。