关于git:Git-不要只会-pull-和-push学学这-5-条提高效率的命令下

8次阅读

共计 1767 个字符,预计需要花费 5 分钟才能阅读完成。

应用 git 作为代码版本治理,早已是当初开发者必备的技能,然而大多数的开发者还是只会最根本的保留,拉去,推送,遇到一些 commit 治理的问题就大刀阔斧,或者用一些不优雅的形式解决。
上面分享一些在开发工作中实际过的实用命令,这些都可能大大提交工作效率,还能解决不少疑难场景。
revert
形容:
给定一个或多个现有提交,复原相干提交引入的更改,并记录一些这些更改的新提交,这就要求你的工作树是洁净的(没有来自头部的批改)。
将现有的提交还原,复原提交的内容,并生成一条还原记录。
利用场景:
利用场景:有一天测试忽然跟你说,你开发上线的性能有问题,须要马上撤回,否则会影响到零碎应用,这时可能会想到用 reset 回退,可是你看了看分支上最新的提交还要其它共事的代码,用 reset 会把这部分代码也撤回了,因为情况紧急,又想不到好办法,还是兽性的应用 reset,而后再让共事把他的代码合一遍(共事听到想打人),于是你的技术形象在共事眼里一泻千里。

命令应用:
revert 一般提交
学会 revert 之后,立马就能够援救这种难堪的状况
当初 master 记录如下:

revert 掉本人提交的 commit.

因为 revert 会生成一条新的提交记录,这时会让你编辑提交信息,编辑完后:wq 保留退出就好了。

再来看下最新的 log,生成一条 revert 记录,尽管本人之前的提交记录还会保留着,但你批改的代码曾经被撤回了。
revert 合并提交
在 git 的 commit 记录里,还有一种类型是合并提交,想要 revert 合并提交,应用上会有些不一样。

当初的 master 分支里多了条合并提交。

应用刚刚同样的 revert 办法,会发现命令行报错了。
为什么会这样,在官网文档中有承受:
通常无奈 revert 合并,因为您不晓得合并的哪一侧应被视为主线,此选项指定的父编号(从 1 开始),并容许 revert 反转绝对于指定父编号的更改
我的了解是因为合并提交是两条分支的交加节点,而 git 不晓得须要撤销的哪一条分支,须要增加参数 - m 指定主线分支,保留主线分支的代码,另一条则被撤销。

revert 合并提交后,再次合并分支会生效
还是下面的场景,在 master 分支 revert 合并提交后,而后切到 v2.0 分支修复好 bug,再合并到 master 分支时,会发现之前被 revert 的批改内容没有从新合并进来。
因为应用 revert 后,v2.0 分支的 commit 还是会保留再 master 分支的记录中,当你再次合并进去时,git 判断有雷同的 commitHash,就疏忽了相干的 commit 需改内容。

当初 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 短命令对于我这种喜爱桥命令行而不必图形化工具的爱好者来说,设置短命令能够很好的提高效率,上面介绍两种设置短命令的形式。形式一:

形式二:关上全局配置文件

写入内容

应用

源码附件曾经打包好上传到百度云了,大家自行下载即可~

链接: https://pan.baidu.com/s/14G-b…
提取码: yu27
百度云链接不稳固,随时可能会生效,大家放松保留哈。如果百度云链接生效了的话,请留言通知我,我看到后会及时更新~
开源地址
码云地址:http://github.crmeb.net/u/defu
Github 地址:http://github.crmeb.net/u/defu

正文完
 0