前言 使用Git作为代码版本管理,早已是现在开发工程师必备的技能。可大多数工程师还是只会最基本的保存、拉取、推送,遇到一些commit管理的问题就束手无策,或者用一些不优雅的方式解决。 本文分享我在开发工作中实践过的实用命令。这些都能够大大提高工作效率,还能解决不少疑难场景。下面会介绍命令,列出应用场景,手摸手教学使用,让同学们看完即学会。 stash 官方文档 git教程描述 官方解释:当您想记录工作目录和索引的当前状态,但又想返回一个干净的工作目录时,请使用gitstash。该命令将保存本地修改,并恢复工作目录以匹配头部提交。 stash命令能够将还未commit的代码存起来,让你的工作目录变得干净。应用场景 我猜你心里一定在想:为什么要变干净? 应用场景:某一天你正在feature分支开发新需求,突然产品经理跑过来说线上有bug,必须马上修复。而此时你的功能开发到一半,于是你急忙想切到master分支,然后你就会看到以下报错: 因为当前有文件更改了,需要提交commit保持工作区干净才能切分支。由于情况紧急,你只有急忙commit上去,commit信息也随便写了个暂存代码,于是该分支提交记录就留了一条黑历史。。。(真人真事,看过这种提交)命令使用 如果你学会stash,就不用那么狼狈了。你只需要:gitstash 就这么简单,代码就被存起来了。 当你修复完线上问题,切回feature分支,想恢复代码也只需要:gitstashapply相关命令保存当前未commit的代码gitstash保存当前未commit的代码并添加备注gitstashsave备注的内容列出stash的所有记录gitstashlist删除stash的所有记录gitstashclear应用最近一次的stashgitstashapply应用最近一次的stash,随后删除该记录gitstashpop删除最近的一次stashgitstashdrop 当有多条stash,可以指定操作stash,首先使用stashlist列出所有记录:gitstashliststash{0}:WIPon。。。stash{1}:WIPon。。。stash{2}:On。。。 应用第二条记录:gitstashapplystash{1} pop,drop同理。vscode集成 stash代码 填写备注内容,也可以不填直接Enter 在STASHES菜单中可以看到保存的stash 先点击stash记录旁的小箭头,再点击apply或者pop都可恢复stash resetsoft 官方文档 git教程描述 完全不接触索引文件或工作树(但会像所有模式一样,将头部重置为)。这使您的所有更改的文件更改为要提交的更改。 回退你已提交的commit,并将commit的修改内容放回到暂存区。 一般我们在使用reset命令时,gitresethard会被提及的比较多,它能让commit记录强制回溯到某一个节点。而gitresetsoft的作用正如其名,soft(柔软的)除了回溯节点外,还会保留节点的修改内容。应用场景 回溯节点,为什么要保留修改内容? 应用场景1:有时候手滑不小心把不该提交的内容commit了,这时想改回来,只能再commit一次,又多一条黑历史。 应用场景2:规范些的团队,一般对于commit的内容要求职责明确,颗粒度要细,便于后续出现问题排查。本来属于两块不同功能的修改,一起commit上去,这种就属于不规范。这次恰好又手滑了,一次性commit上去。命令使用 学会resetsoft之后,你只需要:恢复最近一次commitgitresetsoftHEAD resetsoft相当于后悔药,给你重新改过的机会。对于上面的场景,就可以再次修改重新提交,保持干净的commit记录。 以上说的是还未push的commit。对于已经push的commit,也可以使用该命令,不过再次push时,由于远程分支和本地分支有差异,需要强制推送gitpushf来覆盖被reset的commit。 还有一点需要注意,在resetsoft指定commit号时,会将该commit到最近一次commit的所有修改内容全部恢复,而不是只针对该commit。 举个栗子: commit记录有c、b、a。 reset到a。gitresetsoft1a900ac29eba73ce817bf959f82ffcb0bfa38f75 此时的HEAD到了a,而b、c的修改内容都回到了暂存区。 cherrypick 官方文档 gitcherrypick教程描述 给定一个或多个现有提交,应用每个提交引入的更改,为每个提交记录一个新的提交。这需要您的工作树清洁(没有从头提交的修改)。 将已经提交的commit,复制出新的commit应用到分支里应用场景 commit都提交了,为什么还要复制新的出来? 应用场景1:有时候版本的一些优化需求开发到一半,可能其中某一个开发完的需求要临时上,或者某些原因导致待开发的需求卡住了已开发完成的需求上线。这时候就需要把commit抽出来,单独处理。 应用场景2:有时候开发分支中的代码记录被污染了,导致开发分支合到线上分支有问题,这时就需要拉一条干净的开发分支,再从旧的开发分支中,把commit复制到新分支。命令使用复制单个 现在有一条feature分支,commit记录如下: 需要把b复制到另一个分支,首先把commitHash复制下来,然后切到master分支。 当前master最新的记录是a,使用cherrypick把b应用到当前分支。 完成后看下最新的log,b已经应用到master,作为最新的commit了。可以看到commitHash和之前的不一样,但是提交时间还是保留之前的。复制多个 以上是单个commit的复制,下面再来看看cherrypick多个commit要如何操作。一次转移多个提交:gitcherrypickcommit1commit2 上面的命令将commit1和commit2两个提交应用到当前分支。多个连续的commit,也可区间复制:gitcherrypickcommit1。。commit2 上面的命令将commit1到commit2这个区间的commit都应用到当前分支(包含commit1、commit2),commit1是最早的提交。cherrypick代码冲突 在cherrypick多个commit时,可能会遇到代码冲突,这时cherrypick会停下来,让用户决定如何继续操作。下面看看怎么解决这种场景。 还是feature分支,现在需要把c、d、e都复制到master分支上。先把起点c和终点e的commitHash记下来。 切到master分支,使用区间的cherrypick。可以看到c被成功复制,当进行到d时,发现代码冲突,cherrypick中断了。这时需要解决代码冲突,重新提交到暂存区。 然后使用cherrypickcontinue让cherrypick继续进行下去。最后e也被复制进来,整个流程就完成了。 以上是完整的流程,但有时候可能需要在代码冲突后,放弃或者退出流程:放弃cherrypick:gitscherrypickabort 回到操作前的样子,就像什么都没发生过。退出cherrypick:gitcherrypickquit 不回到操作前的样子。即保留已经cherrypick成功的commit,并退出cherrypick流程。revert 官方文档描述 给定一个或多个现有提交,恢复相关提交引入的更改,并记录一些这些更改的新提交。这就要求你的工作树是干净的(没有来自头部的修改)。 将现有的提交还原,恢复提交的内容,并生成一条还原记录。应用场景 应用场景:有一天测试突然跟你说,你开发上线的功能有问题,需要马上撤回,否则会影响到系统使用。这时可能会想到用reset回退,可是你看了看分支上最新的提交还有其他同事的代码,用reset会把这部分代码也撤回了。由于情况紧急,又想不到好方法,还是任性的使用reset,然后再让同事把他的代码合一遍(同事听到想打人),于是你的技术形象在同事眼里一落千丈。命令使用revert普通提交 学会revert之后,立马就可以拯救这种尴尬的情况。 现在master记录如下: gitrevert21dcd937fe555f58841b17466a99118deb489212 revert掉自己提交的commit。 因为revert会生成一条新的提交记录,这时会让你编辑提交信息,编辑完后:wq保存退出就好了。 再来看下最新的log,生成了一条revert记录,虽然自己之前的提交记录还是会保留着,但你修改的代码内容已经被撤回了。revert合并提交 在git的commit记录里,还有一种类型是合并提交,想要revert合并提交,使用上会有些不一样。 现在的master分支里多了条合并提交。 使用刚刚同样的revert方法,会发现命令行报错了。 为什么会这样?在官方文档中有解释。 通常无法revert合并,因为您不知道合并的哪一侧应被视为主线。此选项指定主线的父编号(从1开始),并允许revert反转相对于指定父编号的更改 我的理解是因为合并提交是两条分支的交集节点,而git不知道需要撤销的哪一条分支,需要添加参数m指定主线分支,保留主线分支的代码,另一条则被撤销。 m后面要跟一个parentnumber标识出主线,一般使用1保留主分支代码。gitrevertm1commitHashrevert合并提交后,再次合并分支会失效 还是上面的场景,在master分支revert合并提交后,然后切到feature分支修复好bug,再合并到master分支时,会发现之前被revert的修改内容没有重新合并进来。 因为使用revert后,feature分支的commit还是会保留在master分支的记录中,当你再次合并进去时,git判断有相同的commitHash,就忽略了相关commit修改的内容。 这时就需要revert掉之前revert的合并提交,有点拗口,接下来看操作吧。 现在master的记录是这样的。 再次使用revert,之前被revert的修改内容就又回来了。reflog 官方文档描述 此命令管理重录中记录的信息。 如果说resetsoft是后悔药,那reflog就是强力后悔药。它记录了所有的commit操作记录,便于错误操作后找回记录。应用场景 应用场景:某天你眼花,发现自己在其他人分支提交了代码还推到远程分支,这时因为分支只有你的最新提交,就想着使用resethard,结果紧张不小心记错了commitHash,reset过头,把同事的commit搞没了。没办法,resethard是强制回退的,找不到commitHash了,只能让同事从本地分支再推一次(同事瞬间拳头就硬了,怎么又是你)。于是,你的技术形象又一落千丈。命令使用 分支记录如上,想要reset到b。 误操作reset过头,b没了,最新的只剩下a。 这时用gitreflog查看历史记录,把错误提交的那次commitHash记下。 再次reset回去,就会发现b回来了。设置Git短命令 对我这种喜欢敲命令而不用图形化工具的爱好者来说,设置短命令可以很好的提高效率。下面介绍两种设置短命令的方式。 方式一gitconfigglobalalias。pspush 方式二 打开全局配置文件vim。gitconfig 写入内容〔alias〕cocheckoutpspushplpullmermergenoffcpcherrypick 使用等同于gitcherrypickcommitHashgitcpcommitHash总结 本文主要分享了5个在开发中实用的Git命令和设置短命令的方式。stash:存储临时代码。resetsoft:软回溯,回退commit的同时保留修改内容。cherrypick:复制commit。revert:撤销commit的修改内容。reflog:记录了commit的历史操作。 文中列举的应用场景有部分不太恰当,只是想便于同学们理解,最重要的是要理解命令的作用是什么,活学活用才能发挥最大功效。 如果你也有一些实用的Git命令也欢迎在评论区分享