linux中git命令有什么用(git命令,linux,开发技术)

前言

因为结合了开发中可能遇到的场景，篇幅较长，不过我觉得很有助于你理解 git 的运作机制，而不是死记硬背命令。

HEAD指针 始终指向的是当前分支的最新版本号，HEAD^, HEAD^^, ^ 的个数 n 或 HEAD~n，n 代表前 n 个版本号。

在项目中直接使用 linux rm 只会删除工作区的文件，git rm 同在删除工作区文件的同时删除 stage 中的，或使用 git rm --cached 只删除 stage 中的。

一些基本的操作

checkout

checkout 命令有两个主要作用：切换分支 和 回滚文件到当前的 stage 版本 或 repository 版本

1、切换分支

2、回滚工作区的文件到最新 stage 版本 或 repository 版本，即从 stage 或 repository 中检出最新版本

回滚时会先检查 stage 中是否有对应的文件，如果没有才会使用 repository 中最新的版本。而当对某文件进行了多次修改和 add 操作后，使用 checkout 我们只能将文件回滚到最新一次的 add 的版本。

但在某些场景下我们可能想回滚到 repository 中的最新版本，怎么做呢？配合 reset 命令的可以很容易做到。
先给出命令：

这样就可以将工作区的 filename 回滚到 repository 中的最新版本了。具体原理我们将在实例中详细的讲解。

reset

git 的 reset 命令比较绕，需要耐心的理解。简单来说，reset 有三种重置级别，我们需要准确理解每个级别的作用。

soft：回退版本号。作用于 repository

mixed：回退版本号，重置 stage。作用于 repository 和 stage

hard ：回退版本号，重置 stage，重置工作区源码。作用于 repository，stage 和 workspace

我们简单展示下 repository 的版本号，我们以此为 demo 分别尝试三个级别的 reset

命令格式：

--soft：只是单纯的移动 repository 的 HEAD指针 到制定版本号。stage 和工作区没有任何变化。

--mixed：默认选项，移动 repository 的 HEAD指针 到指定版本号，同时用此版本重置 stage 区，所以可能会让工作区的某些文件处于 unstage 状态（当工作区的文件与 repository 中的版本不一致时）。注意，这里是可以指定文件的。soft 本身和文件无关，hard 则是不能单独指定文件，只能全部重置。

HEAD指针 指向 version B，并且 stage 已经被 version B 的文件重置，工作区则不受影响。

这里有个很实用的小技巧：

这两个命令组合在一起可以让工作区的指定文件回滚到 repository 中对应的 version_no 版本。
如果 version_no 是 HEAD 的话那就可以回滚文件到最新一次的提交。

--hard：谨慎使用！！！移动 repository 的 HEAD指针 到指定版本号，同时用此版本重置 stage 区 和 工作区源码。这里要特别注意，工作区的源码也会被覆盖重置掉，你的修改会全部丢失。简单来说就是将代码彻底恢复到指定版本。hard 是没办法指定文件的，要么回滚，要么全回滚。

此时，HEAD指针 指向 version A，并且 stage 和 工作区的文件已经被 version A 的文件重置。整个项目的状态完全回到提交 version A 时按下回车键的那一刻。

rm

git rm 不同于直接使用 rm，git rm 会删除工作区 和 stage 区的内容。注意：这里你没办法再使用 git checkout -- <filename> 来回滚操作了，因为工作区也没有 filename 文件了，没办法与 repository 做关联，只能使用 git reset HEAD <filename> 来重置 stage 中的此文件，然后 git checkout -- <filename>

这里就提示一点，只想把 stage 中的文件删除掉让文件脱离 git 的管理，可以使用

此时工作区的 filename 并不会被删除，但状态会被改为 untracked，同时 stage 会记录下 filename 的状态为删除，提交的话版本库将新增一个 filename 被删除掉的版本。

删除 stage 中的文件和使用 reset命令 重置 stage 中的文件是有区别的，删除会让文件状态更改为 untracked，而重置会让文件状态更改为 unstage（如果工作区和 stage 文件内容不一致）。

小实例场景：

1、回滚工作区某文件到指定的 repository 版本

工作中，我们可能会针对某文件做多次修改和 add 到 stage 的操作，而后发现思路完全错了，需要重新设计开发。

比如文件 foo 的 A版 我提交了一次后，又进行了 B版 和 C版 的两次修改并 add 到了 stage 区。第三次修改后 D版 我发现一开始思路就错了，需要重新设计。那此时直接使用 git checkout -- foo 是拿不到最初的 A版 的，因为 stage 区还存放着 foo 的 C版。此时我们便可以使用 git reset HEAD foo 命令，repository 最新版本号中存放着 foo 的 A版，命令会在不移动 HEAD 的前提下，使用 foo A版 去重置 stage 区。命令执行后 stage 区的 foo 文件已经是 A版 了。我们再使用 git checkout -- foo 便可以将工作区的 foo D版 回滚至 A 版。即：

HEAD 代表当前版本，所以 HEAD指针 不会移动。同时 stage 区会被 repository 的当前版本的 filename 重置，也就说 stage 区 存放的 filename 与 repository 中相同了。此时我们再使用 git checkout -- <filename> 便可以回滚工作区的 filename 到 repository 的当前版本。其实就是利用 reset --mixed 会重置 stage 区，然后 checkout 会将 stage 区的文件检出到工作目录。当然，reset 很灵活，可以回滚任意指定的版本。

其实如果只是回滚至当前版本的话，还有个命令能实现相同的功能

git rm --cached <filename> 会将 stage 中的此文件删除，文件状态会变为 untracked，然后 checkout 时发现 stage 中木有此文件，故会去 repository 的当前版本中检出此文件。

diff

git diff -- <filename> 工作区 比较 暂存区

git diff --cached -- <filename> 暂存区 比较 本地库当前版本

git diff HEAD~N -- <filename> 工作区 比较 本地库第N个版本

git diff HEAD HEAD^ -- <filename> HEAD 比较 HEAD^

git diff master tmp -- <filename> master 比较 tmp

git diff SHA1 SHA2 -- <filename> 比较两个历史版本之间的差异