git中暂存区的用途是什么

问题描述

我是git的新手.

我只是在讨论工作目录和暂存区的概念.

我对暂存区的使用不是很清楚.

如果暂存区不存在，而我们可以直接从工作目录提交到本地存储库，那又怎么可能呢?

道歉，如果我的问题很愚蠢.

感谢您，京东

解决方案

您的问题一点都不傻.它是建立整个Git大厦的为数不多的基础概念之一.

• 工作目录是您正在使用的实际位置，您可以在检出文件时查看文件，并且其中包含 .git 子目录.这将形成您的git存储库，以及您最初克隆的git存储库的本地副本.
• 索引是Git实际跟随的文件列表:它是由一个单一的，扁平的二进制文件形成的，该文件包含 .git 下大小固定的条目.子目录，简称为 index .这意味着工作目录中所有未显式跟随Git的文件将始终保持不变.

您还需要知道Git是基于快照的SCM系统:每次修改文件时，它都会再次被完全记录.Git不会记录版本之间的差异(至少不是在此阶段).因此，每个提交都是由树状文件列表构成的，这些文件列表引用了每个文件的当前版本.

这就是索引开始聪明的地方:当您使用 git add 将文件添加到跟踪列表时，您并不仅仅是在索引中添加其名称和路径:Git还会保存其索引对象中的当前内容，从而开始构建实际的最新提交的有效负载.然后，当您执行 git commit 时，git只会将该索引的内容另存为新修订版.这就是使事实上该索引成为暂存区"的原因.

这有几个后果:

• 在您的新提交中实际记录的实际上是文件的状态，就像您执行 git add 时一样，而不是 git commit ；
• 您可以轻松决定要实际提交的内容:您不必强制提交自上次提交以来已修改的每个跟踪文件；
• 要确定存储库的状态，git只需比较工作目录，索引和最后一次提交(实际上是HEAD当前引用的提交)的状态.

我们可以通过以下内容总结最后一点:

• 所有工作目录，索引和最后一次提交都引用相同的文件内容:存储库是最新的:
• 索引和提交相同，但工作目录包含不同的文件内容:已进行了一些修改，需要添加:未分级的更改"；
• 工作目录和索引相同，但是与上一次提交不同:已经进行了一些修改并标记为记录:分阶段的更改"；
• 所有三个实体都不相同:某些更改已更改，但是自上次调用 git add (仍然完全合法)以来，您又再次修改了文件，或者您执行了基于部分添加的操作在使用 git add -p 的补丁块上，仅选择文件中有趣的部分:已暂存的更改"和未暂存的更改"都以 git状态出现.

最后，这提供了最后但并非最不重要的优势:由于修改检测是基于文件内容而不是基于文件的最后修改时间，因此您可以轻松地取消所做的事情.当文件偶然地"恢复到开始时的状态时，它将自动从 git status 的列表中消失.

I am very new in git.

I was just going through the concept of working directory and staging area.

i am not very much clear about the use of staging area.

What could be wrong, if staging area is not there and we could able to commit directly from working directory to local repo?

Apology, if my question is silly.

Thanks with Regards,JD

解决方案

Your question is not silly at all. It's one of the few underlying concepts founding the whole Git's edifice.

• The working directory is the actual place you're working in, you can see your files when they're checked out, and that contains (among others things) the .git subdirectory. This forms your git repository, as well as your local copy of a remote one if you initially cloned it.
• The index is the list of files that are actually followed by Git : it's formed by a single, flat, binary file containing size-fixed entries under the .git subdirectory, simply named index. This means that all files located in the working directory that are NOT explicitly followed by Git will always remain untouched.

You also need to know that Git is a snapshot-based SCM system : each time a file is modified, it's entirely recorded again. Git won't record the diff between version (at least, not at this stage). Each commit is therefore formed by a treeish file list referencing current versions of each of them.

That's where the index starts to be clever : when you add a file to the tracking list using git add, you're not simply adding its name and path to the index : Git also saves its current content in a object, thus starting to build the actual up-to-come commit's payload. When you then do git commit, git simply saves the content of this index as a new revision. This is what makes de facto this index a "staging area".

This has several consequences:

• What's actually recorded in your new commit is actually the state of the file as it was when you did git add, not git commit ;
• You can easily decide what you will actually commit: you're not forced to commit every tracked file that have been modified since the last commit ;
• To determine what is the status of your repository, git simply needs to compare the states of the working directory, the index and the last commit (actually the one currently referenced by HEAD).

We can summarize this very last point by the following:

• All working dir, index and last commit are referencing the same file content : the repository is up to date :
• index and commit are the same, but working dir contains different file content : some modifications have been made and need to be added : "unstaged changes" ;
• working dir and index are the same, but differ with last commit : some modifications have been made and have been marked for recording : "staged changes" ;
• All three entities are different : some modifications have been changed, but you've modified your files again since last time you called git add (which remains perfectly legal) or you performed a partial addition based on patch hunks with git add -p to select only what's interesting in a file: both "staged changes" and "unstaged changes" are showing up in git status.

Finally, this gives a last but not least advantage : since modification detection is based on file content and not on its last modification time, you can easily cancel what you've done. When the file "accidently" goes back to what it was at the beginning, it will automatically disappear from git status's list.

这篇关于git中暂存区的用途是什么的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持！