05、git其他常用命令介绍

前面四节我们对git概念以及一些常用的命令做了介绍,但是考虑到文章的篇幅和连贯性,将一些实际也很重要的命令集中到本节博客做个补充。
本节内容预告:

1.git删除和移动
2.标签,diff和blame
3.checkout 和stash

1.git 删除和移动

这个主要是为了对比一下,我们和实际的直接删除移动命令有什么不一样。

1.1 重命名文件

可以看到,刚开始我们有一个test.txt 的文件,然后通过linux的命令重命名为test2.txt,然后使用命令git status,git 提示我们可以使用git add 命令添加内容到暂存区,另外还要留意到,我们重命名一个文件git实际上是理解为我们先创建一个新的文件,然后再删除旧的文件,注意这里直接添加会git有个报错:
在这里插入图片描述
git提示我们不能直接使用命令git add .,需要使用git add -A来添加这个变更,最后使用commi提交变更到版本库。
在这里插入图片描述
如果使用git提供给我们的命令怎么操作呢?
使用git mv 文件名 新的文件名,这样就会变更保存到了暂存区,然后我们需要做的就是使用commit提交这个变更,通过和上面的对比,可以发现,使用git mv实际上是做了两步操作,一步是在工作区变更,另一步是保存到暂存区
在这里插入图片描述

1.2 git rm 命令

git rm 命令实际上也是两步操作,和上面的git mv类似,这里就不再赘述了,有兴趣可以自己本地尝试
在这里插入图片描述
在这里插入图片描述

2.tag,diff和blame

2.1 git tag

我们在日常的版本迭代更新中偶尔会有一个重大的迭代更新,比如产品1.0初版上线等这种里程碑式的发版,需要做个标签记录下来。

因为我们前面说过git每次提交都会有一个提交id生成,但是因为提交id是一个sha1值,很不好记忆,然后我们是通过提交信息来标记这次提交的。想象一下,当你的版本一直迭代开发,有成白上千次提交的时候,这时候想要从这么多提交信息里面找到一个你想要的版本是比较头疼的,而且如果有相似的提交信息更容易混乱。

基于类似种种原因,git给我们提供了一个标签的功能,简而言之就是给我们当前发版的稳定分支打一个标签,这样后面需要找这种版本的时候,就不会去提交记录里面翻找,而是在tag里面查看,需要注意tag需要有明确意思,比如那个项目-那个日期-上线内容-版本号等,这样更容易找到对应的版本,也避免时间长了后区分不清楚tag是哪个版本的。

初学这个的时候感觉这个没啥作用,我们上次发生产环境后因为代码需要迁移到客户的版本库,算是一个里程碑式的标记,所以就想着打一个标签,当然还有一种比较low的做法是在原来分支基础上新拉一个分支,然后后续版本迭代在新的分支上面,不动原来分支代码。。。

下面简单介绍一下tag使用命令

  1. git tag v1.0
    这个命令是基于当前分支最新的提交创建一个v1.0的标签
  2. git tag -l
    查看当前所有标签,后面可以跟参数实现模糊查找和精确查找
    在这里插入图片描述
  3. git tag -a 'name' -m ’注释‘
    可以给你的tag加注释
    在这里插入图片描述
  4. git tag -d v1.0
    删除某个tag
    关于标签,暂时就展开这么多,这里需要留意,tag是不依赖于某个分支的,简单来说就是你在这个分支打的标签,在其他分支也能正常查看使用。

2.2 git blame

我们经常会遇见一种情况是,一个文件被很多人修改过,但是你不清楚有问题的那块代码最后一次是被谁修改的,什么时候修改的。
git给我们提供了一个功能,可以看到一个文件的每行代码,是被谁修改的,什么时候修改的。这就是git blame。使用命令git blame 文件名可以看到如下,每行最后一次修改的时间,作者是谁,提交id,这样可以很方便的定位到具体是谁修改的代码,这个命令关键时刻很管用,后面也会讲git和idea集成的时候的使用方式
在这里插入图片描述
这个命令可以跟很多参数,这里就不展开了,感兴趣可以通过git blame --help查看具体使用方式或者访问git官网

2.3 git diff

在了解git diff之前,我们先了解一下linux自带的diff命令
在linux中,diff命令用于逐行比较两个文件的差异,例子如下:有两个文件内容如图所示
在这里插入图片描述

在这里插入图片描述
上面的1,3c1,5的意思是,左边的文件一到三行和有边的文件一到五行比较,
箭头向左表示左边的文件减三行,向右表示左边的文件加五行,这样就会和右边的文件一样。
在这里插入图片描述
如上所示,通过加参数diff -u 文件一 文件二以合并的方式展示文件的差异,这种方式就比较明了了,很显然看到左边的文件减去一到三行,加上1,5行会和右边的文件一致。
那么git diff怎么使用呢?

git-diff - Show changes between commits, commit and working tree, etc

这是git官网对git diff的介绍,展示提交之间以及提交和工作目录之间的改变等等,这个命令在我们日常代码版本维护中也是经常会用到的一个命令。

  1. git diff 比较工作区与暂存区的差异
  2. git diff --cached 比较暂存区与版本库差异
  3. git diff HEAD 比较工作区与版本库的差异
  4. git diff test 不带分支的时候,我们比较的是当前分支的,加了分支我们比较test分支
  5. git diff HEAD – ./test 比较当前分支,但是限制只比较test这个文件
  6. git diff HEAD^ HEAD 比较上次提交和上上次提交
  7. git diff topic master 或者 git diff topic…master 比较topic分支和master分支之间差异
  8. git diff topic…master 比较自从topic从master新创建后,master和topic的差异
  9. git diff --diff-filter=MRC 仅展示修改,重命名和复制,不展示新增和删除
    这边列举了一些常见的,更多高级用法见git diff 官网

3. stash 和 checkout

3.1 checkout简单回顾

关于checkout前面有多个地方提到,容易混乱,这里简单回顾一下。
我们再提到代码 版本回滚的时候,讲到可以通过命令git checkout -- 文件名 丢弃工作区相对于暂存区的变更,修改的是工作区的内容
然后还可以通过命令git checkout 提交id ,直接将代码回滚到对应提交
分支切换的时候,当我们想切换的一个分支时,使用命令git checkout test,这样就会切换到test分支。

3.2 stash

比较有经验的开发肯定会遇见下面的场景:
有一个需求开发到一半,突然有一个紧急的需求或者线上的bug要修改,这时候需要从主分支新拉一个分支修改bug,问题是当两个分支指针不一样时,一个分支本地有修改后,如果有紧急需求需要切换到另一个分支是不可以的,因为会丢失修改内容,此时可以选择提交修改解决报错,但是因为代码没开发完,提交内容不能保证正常运行,所以需要用到stash

Use git stash when you want to record the current state of the working directory and the index, but want to go back to a clean working directory. The command saves your local modifications away and reverts the working directory to match the HEAD commit.
这段话是我在官网摘抄的,大意是:当你想当前工作区和暂存区的状态,但是想要一个干净的工作区时,用git stash,这个命令保存了你的本地改变,而且转换你本地工作区的内容与最新的提交保持一致。

3.2.1 git stash save ‘临时保存’

在这里插入图片描述
可以看到上面刚开始有两个文件要提交,通过git stash save 命令,将保存的内容保存起来。

3.2.2 git stash list

列举当前有多少个stash,执行命令git stash list在这里插入图片描述

3.2.3 git stash pop

恢复工作现场,同时会将缓存的stash内容删除,可以看到内容恢复,此时使用git stash list发现缓存的stash内容删除
在这里插入图片描述

3.2.4 git stash apply

恢复工作现场,保留缓存的stash内容,可以看到内容恢复,此时使用git stash list发现缓存的stash内容仍然存在
在这里插入图片描述
注:stash可以缓存多次,此时如果单纯使用git stash pop或者 git stash apply,默认会恢复最新的也就是图示最上面的内容,可以通过指定参数,如git stash pop stash@\{0\},来告诉git,你想恢复的是哪一个内容
在这里插入图片描述
最后,我们根据官网的例子,代入一个使用场景:

When you are in the middle of something, you learn that there are upstream changes that are possibly relevant to what you are doing. When your local changes do not conflict with the changes in the upstream, a simple git pull will let you move forward.
你一个需求开发到一半发现,同事改了部分代码,而且这部分代码是你要用到的,此时,如果你本地代码和同事已经提交的代码没有冲突的话, 你可以简单通过git pull命令获取远程更新,本地相当于一个简单的向前移动。
However, there are cases in which your local changes do conflict with the upstream changes, and git pull refuses to overwrite your changes. In such a case, you can stash your changes away, perform a pull, and then unstash, like this:
但是,常见的是,你的同事提交的的代码和你本地的有冲突,git pull 命令拒绝覆盖你本地的代码变更,就是说,git pull ,默认不会强制覆盖你的本地变更,这样也很合理,不然可能会造成工作内容的丢失。在这种情况下:你可以先通过stash命令将你的变更保存到其他地方,然后本地就是干净的,通过pull命令获取远程变更,最后在通过pop命令恢复你的本地变更,此时应该会有冲突,你要做的就是解决本地解决冲突就好。如下:
$ git pull

file foobar not up to date, cannot merge.
$ git stash
$ git pull
$ git stash pop

另一个例子:

When you are in the middle of something, your boss comes in and demands that you fix something immediately. Traditionally, you would make a commit to a temporary branch to store your changes away, and return to your original branch to make the emergency fix, like this:
当你一个需求做到一半,老板过来让你马上改一个线上紧急的bug,通常来说,你可以创建一个临时的分支保存你的提交,然后切换到原始分支改bug,改完没问题后,再切回你的临时分支继续coding,coding,coding…

… hack hack hack …
$ git switch -c my_wip
$ git commit -a -m “WIP”
$ git switch master
$ edit emergency fix
$ git commit -a -m “Fix in a hurry”
$ git switch my_wip
$ git reset --soft HEAD^
… continue hacking …
You can use git stash to simplify the above, like this:
你也可以使用下面的方式:
#… hack hack hack …
$ git stash
$ edit emergency fix
$ git commit -a -m “Fix in a hurry”
$ git stash pop
… continue hacking …

至此,git一些比较常见的命令我们基本介绍完毕,细心的读者会发现,当前我们基本上虽说有时候会在一些案例中穿插的讲到一些远程的命令,但是还没有系统的陈述介绍,下节我们开始介绍远程命令与多人协作等。

下节预告:
1.git关联远程仓库,以github为例
2.git协作
3.git远程分支,别名,以及git可视化界面简介

最后,感谢阅读,如有错误,请不吝指正

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章