当前位置:首页 » 硬盘大全 » git为啥有缓存区
扩展阅读
webinf下怎么引入js 2023-08-31 21:54:13
堡垒机怎么打开web 2023-08-31 21:54:11

git为啥有缓存区

发布时间: 2023-01-11 09:46:35

‘壹’ 百思不得其解,tortoisegit是把git中的暂存区概念干掉了吗

stage(暂存)这个概念在TortoiseGit中依然存在,只是变得不直观了

原因:

TortoiseGit为了保持和TortoiseSVN近乎一致的使用体验,对“暂存文件”这个步骤进行了操作上的简化:操作者点击提交按钮的瞬间,TortoiseGit会立即stage(暂存)这些文件并commit(提交)它们。注意,这两个操作几乎是先后同时执行的

也就是说,TortoiseGit通过紧密的捆绑git add和git commit这两个指令到一个提交按钮中,在操作层面给人了一种暂存(stage)被干掉了的感觉,但实际上并没有!

在大部分情况下,这个TortoiseGit特有的优化会给带来一些便利

但同时也会导致TortoiseGit对暂存区的表现变得非常不直观。比如TortoiseGit根本没有提供任何一个窗口来表现哪些文件处于暂存区

所以建议,在windows系统下,如果你不擅长通过命令行来使用git,请常备TortoiseGit和SourceTree这2个Git GUI

‘贰’ git 为什么要设立缓存

这样在本地就可以提交代码和回滚代码,而不用连接服务器的时候才能做相关操作。

‘叁’ git中,文件的状态

git中常用的一个命令便是,git status,该命令的作用是查看哪些文件处于什么状态.
可以用 git status 命令查看哪些文件处于什么状态。 如果在克隆仓库后立即使用此命令,会看到类似这样的输出:
echo 'My Project' > README
$ git status
On branch master
Your branch is up-to-date with 'origin/master'.
Untracked files:
(use "git add <file>..." to include in what will be committed)

nothing added to commit but untracked files present (use "git add" to track)

在状态报告中,可以看到,出现了一个untracked files文件,readme.未跟踪的文件意味着在之前的快照(提交)中没有这些文件,git不会自动的将这些文件纳入可追踪的范围,除非需要明确的指出我要跟踪做这些文件.此时,可以执行:
git add readme.txt
再运行git status
$ git status
On branch master
Your branch is up-to-date with 'origin/master'.
Changes to be committed:
(use "git restore --staged <file>..." to unstage)
new file: README
可以看到readme文件处于被追踪的状态中,是被暂存的状态.但是仍然没有commit.

此时,如果我们做了修改,对于一个被追踪的文件,进行了修改,如果你修改了一个CONTRIBUTING.md的已经被追踪的文件,然后运行:
git status
则会出现以下内容:
$ git status
On branch master
Your branch is up-to-date with 'origin/master'.
Changes to be committed:
(use "git reset HEAD <file>..." to unstage)

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)

意思为: 名为CONTRIBUTING.md已经跟踪的文件发生了变化.但是还没有被放入暂存区,如需要暂存本次修改,需要运行git add命令.
git add命令是一个多命令,可以使用将其从未追踪文件变为已追踪文件,还可以将已追踪文件未修改的内容,变为已追踪文件暂存.还能用户合并时将冲突文件标记为已解决的状态等.
此时,运行git status输出为:
git add CONTRIBUTING.md
$ git status
On branch master
Your branch is up-to-date with 'origin/master'.
Changes to be committed:
(use "git reset HEAD <file>..." to unstage)

可以看到,此时输出的意思为:两个文件都已经暂存,在下次commit时,会一起提交到仓库.

假设此时,需要继续在修改CONTRIBUTING.md文件,此时再运行git status命令,会出现:
git status
On branch master
Your branch is up-to-date with 'origin/master'.
Changes to be committed:
(use "git reset HEAD <file>..." to unstage)

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)

此时,CONTRIBUTING.md文件同时出现在暂存区和非暂存区,是因为,git add文件只是暂存了上次执行git add命令时文件的暂存,如若继续暂存,需要继续运行git status
git status
On branch master
Your branch is up-to-date with 'origin/master'.
Changes to be committed:
(use "git reset HEAD <file>..." to unstage)

如果我们需要查看当前工作区文件和暂存区文件的差异,可以使用git diff命令.若要查看已暂存的将要添加到下次提交里的内容,可以用 git diff --staged 命令。 这条命令将比对已暂存文件与最后一次提交的文件差异.

此时,可以进行commit,进行提交啦.现在的暂存区已经准备就绪,可以提交了。 在此之前,请务必确认还有什么已修改或新建的文件还没有 git add 过, 否则提交的时候不会记录这些尚未暂存的变化。 这些已修改但未暂存的文件只会保留在本地磁盘。 所以,每次准备提交前,先用 git status 看下,你所需要的文件是不是都已暂存起来了, 然后再运行提交命令 git commit.

现在你已经创建了第一个提交! 可以看到,提交后它会告诉你,当前是在哪个分支(master)提交的,本次提交的完整 SHA-1 校验和是什么(463dc4f),以及在本次提交中,有多少文件修订过,多少行添加和删改过。

提交记录的是放在暂存区域的快照.任何还未暂存的文件仍然保持已修改的状态,可以在下次提交时纳入版本管理,每次运行一次git commit都是对项目做一次快照,以后可以回到这个状态,或者进行比较.

跳过使用暂存区域
尽管使用暂存区域的方式可以静心准备要提交的细节,但是,有个问题就是繁琐,git提供了一个暂存区域的方式,只要提交的时候,git commit -a,则git会将已经跟踪过的文件暂存起来一起提交.从而省略一次git add,省略的步骤是,将那些已被追踪的文件改为暂存.这是因为 -a 选项使本次提交包含了所有修改过的文件。 这很方便,但是要小心,有时这个选项会将不需要的文件添加到提交中。

查看git提交历史,使用git log命令.会出现下面输出:
$ git log
commit
Author: Scott Chacon [email protected]
Date: Mon Mar 17 21:52:11 2008 -0700

commit
Author: Scott Chacon [email protected]
Date: Sat Mar 15 16:40:33 2008 -0700

commit
Author: Scott Chacon [email protected]
Date: Sat Mar 15 10:31:28 2008 -0700

在不传入任何参数的前提下,git log会按照时间顺序列出所有的提交,按照时间顺序倒排,commit之后是每次提交的SHA-1校验和(是一个十六位的长度为四十的哈希值),以及作者信息和提交说明.

‘肆’ Git清空暂存区

当前暂存区有两个文件antzone.txt和readme.txt。

将暂存区中的内容删除,工作区中对应的文件并不会受到影响。

所谓暂存区实质是.git目录下的index文件,只要将此文件删除,那么就可以认为暂存区被清空。

‘伍’ git中.gitattributes文件有什么用

git是分为三部分,一部分是你自己的文件,另外一个是缓存区,最后一个是本地库。当你修改了自己的文件后,你会git add xx将修改保存到缓存区,然后再用commit推送修改到本地库中。
git push 将本地仓库修改推送到服务器上的仓库中
comiit 是n将本地修改保存到本地仓库中

‘陆’ 【学了就忘】Git原理 — 20.Git对象[tree对象](二)

我们可以先查看一下Git本地库中的对象,如下

我们接下来用三个图,描述一下三个树对象的结构关系。

第一个树对象结构如下图

第二个树对象结构如下图

也可以换Git对象类型表示:

从上图我们可以分析出:

这就是我前面 2-(3) 描述过的 "Git版本库中的5个对象,即表示了项目的2个版本。"

(就先这样理解)

暂存区的概念和相关理解:

暂存区的作用 :除非是绕过暂存区直接提交,否则Git想把修改提交上去,就必须将修改存入暂存区最后才能commit。每次提交的是暂存区所对应的文件快照。

现在有三个树对象(因为执行了三次 write-tree 命令),分别代表了我们想要跟踪项目的三次快照。然而问题依旧:若想重用这些快照,你必须记住这三个树对象的 SHA-1 哈希值。

并且,你也完全不知道是谁保存了这些快照,在什么时刻保存的,以及为什么保存这些快照。

而以上这些,提交对象 commit object 为你保存了这些基本信息。

Git底层命令:

‘柒’ git 跳过暂存区

git标准的工作流程是在工作区(也就是你当前的本地文件)对文件进行修改,然后将跟踪的修改文件通过git add命令添加操暂存区,最后通过git commit 将暂存区的文件提交到本地仓库。
这样的操作有时候是略显繁琐的,git给提供了一个可以直接将工作区的文件提交到本地仓库的方法git commit -a -m '备注',通过这个命令,可以直接将工作区的修改提交到本地仓库。
但是有个需要注意的地方,这个方法只支持已经被跟踪的文件,像下面新增的index.css文件通过这种方式是没办法提交的。

‘捌’ 工作区和暂存区的概念

工作区:就是在电脑里可以看到的目录,这就是工作区。
比如:

之前我们说过当我们新建一个版本库readme.txt的时候,出现了一个.git的东西,这个东西是隐藏的,不算在工作区,是GIt的版本库。

之前说过把文件往Git版本库里添加的时候,是分两步进行的:
1、用git add来添加文件,实际上就是把文件转移到stage中;
2、用git commit来提交文件,实际上就是把所有在stage中的内容提交到当前分支master中
当然可以用git add添加很多次文件,然后一次性用git commit来一次性提交。
例子如下:
我们对readme.txt做如下修改:

然后在learngit这个文件夹内添加一个LICENSE.txt的文件(内容随便写),
我们可以用git status来查看下目前的状态:

可以看到目前的状态是readme.txt是被修改了,而LICENSE.txt没有被添加过。
现在我们使用git add来分别添加两个文件:

现在用git commit来提交文件,并会显示如下:

以上是我看廖雪峰老师的网站,然后做的学习摘抄,无意侵犯老师作品,如有侵犯,我会删除。

‘玖’ Git初始化 暂存区

git --version
git config --global user.name "guoxi.zhang"
git config --global user.email "[email protected]"
删除Git配置文件中某项值
git config --unset --global user.name

如果拥有系统管理员的权限,你希望注册的别名能被其他用户使用,可以执行如下命令:
sudo git config --system alias.ci commit
也可以只执行如下命令,只在本用户的全局配置中添加Git别名
git config --global alias.ci commit
在git命令输出中开启颜色显示
git config --global color.ui true
git init   命令再当前目录完成版本库的初始化
git init <dir> 该命令会自动创建dir目录并在当前目录的dir目录下初始化版本库,所以
mkdir demo     cd demo     git init
相等于 git init demo
运行该命令之后会在demo目录创建一个 .git 的隐藏文件,隐藏的 .git 目录就是Git版本库(又叫仓库,repository)
.git 版本库所在的目录为工作区
在工作区创建一个welcome.txt文件
echo "hello" > welcome.txt
然后将文件条件到版本库中
git add welcome.txt
git commit -m "initialized"
工作区文件内容搜索命令
git grep "工作区文件内容"
在Git工作区的某个子目录下执行操作的时候,会在工作区目录中依次向上递归查找 .git 目录,找到的 .git 目录就是工作区对应的版本库, .git 所在目录就是工作区,在非 .git 工作区执行git命令时会因为找不到 .git 目录报错

显示版本库 .git 目录所在位置
git rev-parse --git-dir
显示工作区根目录
git rev-parse --show-toplevel
相对于工作区根目录的相对目录
git rev-parse --show-prefix
显示从当前目录回退到工作区的根的深度
git rev-parse --show-cp

打开本项目的配置文件
git config -e
打开当前用户的配置文件
git config -e --global
打开系统的配置文件
git config -e --system
优先级是本项目>当前用户>系统

读取INI文件中某项的值
git config <section>.<key>
设置INI文件中某项的值
git config <section>.<key> value
如果对工作区的文件没有做任何修改,Git默认不会执行提交,使用 --allow-empty 参数允许执行空白提交

git diff     工作区与提交任务(暂存区)中相比的差异
git diff HEAD     工作区和HEAD(当前分支)相比
git diff --cached 或者 git diff --staged     暂存区和版本库文件的差异
git checkout -- welcome.txt     撤销工作区中 welcome.txt 尚未提交的更改

git status    git diff   命令扫描工作区变动的原理:先依据 .git/index 文件中记录的(用于跟踪工作区文件的)时间戳,长度等信息判断工作区文件是否改变,如果工作区的时间戳改变了,就说明工作区的文件内容可能被改变了,需要打开文件,读取文件内容,与更改前的原始文件做比较,判断文件内容是否改变。如果判断文件内容没有改变,就将该文件新的时间戳记录到.git/index文件中
文件 .git/index 实际上就是一个包含文件索引的目录树,像是一个虚拟的工作区,在这个虚拟工作区的目录树中,记录了文件名和文件的状态信息(时间戳和文件长度),文件的内容并没有存储在其中,而是保持在Git对象库 .git/objects 目录中,文件索引建立了文件和对象库中对象实体之间的对应关系。下图展示了工作区,版本库的暂存区和版本库之间的关系

git ls-tree -l HEAD 查看当前HEAD指向的目录树

git clean -fd 清空当前工作区中没有加入到版本库的文件和目录
git checkout . 用暂存区内容刷新工作区
git ls-files -s 显示暂存区的目录树

-a 参数会对本地所有的变更的文件执行提交操作,包括对本地修改的文件和删除的文件,但不包括未被版本库跟踪的文件。使用这个命令将失去Git暂存区带来的巨大好处:对提交内容进行控制的能力

‘拾’ git 缓存区

1.  git stash

2.  git stash list

3.  git stash apply

4.  git stash pop

5.  git stash drop

6.  git stash clear

7.  git stash show

8.  git stash diff