首页
学习
活动
专区
圈层
工具
发布
社区首页 >专栏 >Git系列之查看状态

Git系列之查看状态

作者头像
申霖
发布2019-12-27 17:35:22
发布2019-12-27 17:35:22
1.7K0
举报
文章被收录于专栏:小白程序猿小白程序猿

本节来说下 Git 的状态,在日常开发中我们每天都在提交自己的文件到仓库中,有时会存在我们写了很多的功能,都是提交到了缓存区,而没有想仓库内提交,或者我们新增了一个仓库内没有文件,忘记了提交,那么我们如何来查看当前工作去内有哪些文件被更改了,需要做进一步的操作呢?

使用  git  status 命令来查看;

下面来详细的介绍一下git  status命令:

1、检查当前文件状态

如果想查看自己的工作区内有那些文件被更改了,那些文件是新增的,文件都处于什么状态,输入 git  status 命令并回车,如果是刚刚克隆完仓库,并未对工作区进行操作,那么输入git status后会看到:

代码语言:javascript
复制
$ git status
On branch master
nothing to commit, working directory clean

这说明你现在的工作目录相当干净。换句话说,所有已跟踪文件在上次提交后都未被更改过。 此外,上面的信息还表明,当前目录下没有出现任何处于未跟踪状态的新文件,否则 Git 会在这里列出来。 最后,该命令还显示了当前所在分支,并告诉你这个分支同远程服务器上对应的分支没有偏离。 现在,分支名是 “master”,这是默认的分支名。 我们在 Git 分支 会详细讨论分支和引用。

现在,让我们在项目下创建一个新的 README 文件。 如果之前并不存在这个文件,使用 git status 命令,你将看到一个新的未跟踪文件:

代码语言:javascript
复制
$ git status
On branch master 
Untracked files:   (use "git add <file>..." to include in what will be committed)     
README nothing added to commit but untracked files present (use "git add" to track)

在状态报告中可以看到新建的 README 文件出现在 Untracked files 下面。 未跟踪的文件意味着 Git 在之前的快照(提交)中没有这些文件;Git 不会自动将之纳入跟踪范围,除非你明明白白地告诉它“我需要跟踪该文件”, 这样的处理让你不必担心将生成的二进制文件或其它不想被跟踪的文件包含进来。 不过现在的例子中,我们确实想要跟踪管理 README 这个文件。

2、跟踪新文件

使用命令 git add 开始跟踪一个文件。 所以,要跟踪 README 文件,运行:

代码语言:javascript
复制
$ git add README

此时再运行 git status 命令,会看到 README 文件已被跟踪,并处于暂存状态:

代码语言:javascript
复制
$ git status 
On branch master 
Changes to be committed:   (use "git reset HEAD <file>..." to unstage)     
new file:   README

只要在 Changes to be committed 这行下面的,就说明是已暂存状态。 如果此时提交,那么该文件此时此刻的版本将被留存在历史记录中。 你可能会想起之前我们使用 git init 后就运行了 git add (files) 命令,开始跟踪当前目录下的文件。 git add 命令使用文件或目录的路径作为参数;如果参数是目录的路径,该命令将递归地跟踪该目录下的所有文件。

3、暂存已修改文件

现在我们来修改一个已被跟踪的文件。 如果你修改了一个名为 CONTRIBUTING.md 的已被跟踪的文件,然后运行 git status 命令,会看到下面内容:

代码语言:javascript
复制
$ git status 
On branch master Changes to be committed:   (use "git reset HEAD <file>..." to unstage)     
new file:   README 
Changes not staged for commit:   
    (use "git add <file>..." to update what will be committed)   
    (use "git checkout -- <file>..." to discard changes in working directory)     
    modified:   CONTRIBUTING.md

文件 CONTRIBUTING.md 出现在 Changes not staged for commit 这行下面,说明已跟踪文件的内容发生了变化,但还没有放到暂存区。 要暂存这次更新,需要运行 git add 命令。 这是个多功能命令:可以用它开始跟踪新文件,或者把已跟踪的文件放到暂存区,还能用于合并时把有冲突的文件标记为已解决状态等。 将这个命令理解为“添加内容到下一次提交中”而不是“将一个文件添加到项目中”要更加合适。 现在让我们运行 git add 将"CONTRIBUTING.md"放到暂存区,然后再看看 git status 的输出:

代码语言:javascript
复制
$ git add CONTRIBUTING.md 
$ git status 
On branch master Changes to be committed:   (use "git reset HEAD <file>..." to unstage)     
new file:   README     
modified:   CONTRIBUTING.md

现在两个文件都已暂存,下次提交时就会一并记录到仓库。 假设此时,你想要在 CONTRIBUTING.md 里再加条注释, 重新编辑存盘后,准备好提交。 不过且慢,再运行 git status 看看:

代码语言:javascript
复制
$ vim CONTRIBUTING.md 
$ git status 
On branch master Changes to be committed:   (use "git reset HEAD <file>..." to unstage)     
new file:   README     
modified:   CONTRIBUTING.md 
Changes not staged for commit:   
(use "git add <file>..." to update what will be committed)   
(use "git checkout -- <file>..." to discard changes in working directory)     
modified:   CONTRIBUTING.md

怎么回事? 现在 CONTRIBUTING.md 文件同时出现在暂存区和非暂存区。 这怎么可能呢? 好吧,实际上 Git 只不过暂存了你运行 git add 命令时的版本, 如果你现在提交,CONTRIBUTING.md 的版本是你最后一次运行 git add 命令时的那个版本,而不是你运行 git commit 时,在工作目录中的当前版本。 所以,运行了 git add 之后又作了修订的文件,需要重新运行 git add 把最新版本重新暂存起来:

代码语言:javascript
复制
$ git add CONTRIBUTING.md 
$ git status 
On branch master Changes to be committed:   (use "git reset HEAD <file>..." to unstage)     
new file:   README     
modified:   CONTRIBUTING.md

4、状态简览

git status 命令的输出十分详细,但其用语有些繁琐。 如果你使用 git status -s 命令或 git status --short 命令,你将得到一种更为紧凑的格式输出。 运行 git status -s ,状态报告输出如下:

代码语言:javascript
复制
$ git status -s  
M README 
MM Rakefile 
A  lib/git.rb 
M  lib/simplegit.rb 
?? LICENSE.txt

新添加的未跟踪文件前面有 ?? 标记,新添加到暂存区中的文件前面有 A 标记,修改过的文件前面有 M 标记。 你可能注意到了 M 有两个可以出现的位置,出现在右边的 M 表示该文件被修改了但是还没放入暂存区,出现在靠左边的 M 表示该文件被修改了并放入了暂存区。 例如,上面的状态报告显示: README 文件在工作区被修改了但是还没有将修改后的文件放入暂存区,lib/simplegit.rb 文件被修改了并将修改后的文件放入了暂存区。 而 Rakefile 在工作区被修改并提交到暂存区后又在工作区中被修改了,所以在暂存区和工作区都有该文件被修改了的记录。

5、忽略文件

一般我们总会有些文件无需纳入 Git 的管理,也不希望它们总出现在未跟踪文件列表。 通常都是些自动生成的文件,比如日志文件,或者编译过程中创建的临时文件等。 在这种情况下,我们可以创建一个名为 .gitignore 的文件,列出要忽略的文件模式。 来看一个实际的例子:

代码语言:javascript
复制
$ cat .gitignore 
*.[oa] 
*~

第一行告诉 Git 忽略所有以 .o 或 .a 结尾的文件。一般这类对象文件和存档文件都是编译过程中出现的。 第二行告诉 Git 忽略所有以波浪符(~)结尾的文件,许多文本编辑软件(比如 Emacs)都用这样的文件名保存副本。 此外,你可能还需要忽略 log,tmp 或者 pid 目录,以及自动生成的文档等等。 要养成一开始就设置好 .gitignore 文件的习惯,以免将来误提交这类无用的文件。

文件 .gitignore 的格式规范如下:

  • 所有空行或者以 # 开头的行都会被 Git 忽略。
  • 可以使用标准的 glob 模式匹配。
  • 匹配模式可以以(/)开头防止递归。
  • 匹配模式可以以(/)结尾指定目录。
  • 要忽略指定模式以外的文件或目录,可以在模式前加上惊叹号(!)取反。

所谓的 glob 模式是指 shell 所使用的简化了的正则表达式。 星号(*)匹配零个或多个任意字符;[abc]匹配任何一个列在方括号中的字符(这个例子要么匹配一个 a,要么匹配一个 b,要么匹配一个 c);问号(?)只匹配一个任意字符;如果在方括号中使用短划线分隔两个字符,表示所有在这两个字符范围内的都可以匹配(比如 [0-9] 表示匹配所有 0 到 9 的数字)。 使用两个星号(*) 表示匹配任意中间目录,比如`a/**/z` 可以匹配 a/z, a/b/z 或 `a/b/c/z`等。

我们再看一个 .gitignore 文件的例子:

代码语言:javascript
复制
# no .a files
*.a

# but do track lib.a, even though you're ignoring .a files above
!lib.a

# only ignore the TODO file in the current directory, not subdir/TODO
/TODO

# ignore all files in the build/ directory
build/

# ignore doc/notes.txt, but not doc/server/arch.txt
doc/*.txt

# ignore all .pdf files in the doc/ directory
doc/**/*.pdf

6、查看已暂存和未暂存的修改

如果 git status 命令的输出对于你来说过于模糊,你想知道具体修改了什么地方,可以用 git diff 命令。 稍后我们会详细介绍 git diff,你可能通常会用它来回答这两个问题:当前做的哪些更新还没有暂存? 有哪些更新已经暂存起来准备好了下次提交? 尽管 git status 已经通过在相应栏下列出文件名的方式回答了这个问题,git diff 将通过文件补丁的格式显示具体哪些行发生了改变。

假如再次修改 README 文件后暂存,然后编辑 CONTRIBUTING.md 文件后先不暂存, 运行 status 命令将会看到:

代码语言:javascript
复制
$ git status 
On branch master 
Changes to be committed:   (use "git reset HEAD <file>..." to unstage)     
modified:   README 
Changes not staged for commit:   
(use "git add <file>..." to update what will be committed)   
(use "git checkout -- <file>..." to discard changes in working directory)     
modified:   CONTRIBUTING.md

要查看尚未暂存的文件更新了哪些部分,不加参数直接输入 git diff:

代码语言:javascript
复制
$ git diff 
diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md 
index 8ebb991..643e24f 100644 
--- a/CONTRIBUTING.md 
+++ b/CONTRIBUTING.md 
@@ -65,7 +65,8 
@@ branch directly, things can get messy.  
Please include a nice description of your changes when you submit your PR;  
if we have to read the whole diff to figure out why you're contributing  in the first place,
 you're less likely to get feedback and have your change -merged in. +merged in. Also, 
 split your changes into comprehensive chunks if your patch is +longer than a dozen lines.  
 If you are starting to work on a particular area, feel free to submit a PR  
 that highlights your work in progress (and note in the PR title that it's

此命令比较的是工作目录中当前文件和暂存区域快照之间的差异, 也就是修改之后还没有暂存起来的变化内容。

若要查看已暂存的将要添加到下次提交里的内容,可以用 git diff --cached 命令。(Git 1.6.1 及更高版本还允许使用 git diff --staged,效果是相同的,但更好记些。)

代码语言:javascript
复制
$ git diff 
--staged diff 
--git a/README b/README 
new file mode 100644 index 0000000..03902a1 
--- /dev/null 
+++ b/README 
@@ -0,0 +1 
@@ +My Project

请注意,git diff 本身只显示尚未暂存的改动,而不是自上次提交以来所做的所有改动。 所以有时候你一下子暂存了所有更新过的文件后,运行 git diff 后却什么也没有,就是这个原因。

像之前说的,暂存 CONTRIBUTING.md 后再编辑,运行 git status 会看到暂存前后的两个版本。 如果我们的环境(终端输出)看起来如下:

代码语言:javascript
复制
$ git add CONTRIBUTING.md 
$ echo '# test line' >> CONTRIBUTING.md 
$ git status On branch master Changes to be committed:   
(use "git reset HEAD <file>..." to unstage)     
modified:   CONTRIBUTING.md 
Changes not staged for commit:   
(use "git add <file>..." to update what will be committed)   
(use "git checkout -- <file>..." to discard changes in working directory)     
modified:   CONTRIBUTING.md

现在运行 git diff 看暂存前后的变化:

代码语言:javascript
复制
$ git diff 
diff --git a/CONTRIBUTING.md 
b/CONTRIBUTING.md 
index 643e24f..87f08c8 100644 
--- a/CONTRIBUTING.md 
+++ b/CONTRIBUTING.md 
@@ -119,3 +119,4 
@@ at the  
## Starter Projects  
See our [projects list](https://github.com/libgit2/libgit2/blob/development/PROJECTS.md). 
+# test line

然后用 git diff --cached 查看已经暂存起来的变化:(--staged 和 --cached 是同义词)

代码语言:javascript
复制
$ git diff --cached 
diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md 
index 8ebb991..643e24f 100644 
--- a/CONTRIBUTING.md 
+++ b/CONTRIBUTING.md 
@@ -65,7 +65,8 
@@ branch directly, things can get messy.  
Please include a nice description of your changes when you submit your PR;  
if we have to read the whole diff to figure out why you're contributing  
in the first place, you're less likely to get feedback and have your change -merged in. +merged in. 
Also, split your changes into comprehensive chunks if your patch is +longer than a dozen lines.  
If you are starting to work on a particular area, feel free to submit a PR  
that highlights your work in progress (and note in the PR title that it's
本文参与 腾讯云自媒体同步曝光计划,分享自作者个人站点/博客。
原始发表:2019-03-09,如有侵权请联系 cloudcommunity@tencent.com 删除

本文分享自 作者个人站点/博客 前往查看

如有侵权,请联系 cloudcommunity@tencent.com 删除。

本文参与 腾讯云自媒体同步曝光计划  ,欢迎热爱写作的你一起参与!

评论
登录后参与评论
0 条评论
热度
最新
推荐阅读
目录
  • 1、检查当前文件状态
  • 2、跟踪新文件
  • 3、暂存已修改文件
  • 4、状态简览
  • 5、忽略文件
  • 6、查看已暂存和未暂存的修改
领券
问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档