Git中的暂存区有什么用？

Question

什么是点git add .或git add <filename>将其添加到临时区域？为什么不 git commit -m "blabla"呢？

我不明白临时区域的价值.

Answer 1

git中有多种staging用法.一些列表如下: -

1. staging可以帮助你将一个大的更改分成多个提交 - 假设您正在进行大量更改,涉及大量文件和相当多的不同子任务.你实际上没有提交任何这些 - 你就像他们所说的那样"在区域内",你不想考虑以正确的方式拆分提交.(而且你足够聪明,不要让整个事情按照大承诺!).现在,所有更改都经过测试和工作,您需要在几个干净的提交中正确提交所有这些,每个提交都集中在代码更改的一个方面.使用索引,只需暂存每组更改并提交,直到不再有待更改.你也可以使用git gui,或者你可以使用git add -p,或者使用更新的git,git add -e.

2. staging有助于审查更改 - Staging可帮助您在查看复杂提交时"检查"各个更改,并专注于尚未通过审核的内容.让我解释.在您提交之前,您可能会使用git diff查看整个更改.如果您在审核时对每个更改进行分级,您会发现您可以更好地专注于尚未上演的更改.git gui在这里很棒.它的两个左窗格分别显示了未分级和分阶段的更改,您只需单击文件名左侧的图标即可在这两个窗格之间移动文件(stage/unstage).更好的是,您甚至可以对文件进行部分更改.在git gui的右侧窗格中,右键单击您批准的更改并选择"stage hunk".只是改变了(不是整个文件)现在上演了; 事实上,如果同一个文件中还有其他未分阶段的更改,您会发现该文件现在显示在左上窗格和左下窗格中!

3. 合并发生冲突时,staging有帮助 - 当合并发生时,干净地合并的更改将在暂存区域和工作树中更新.只有当你执行git diff时,或者在git gui的左上方窗格中,才会显示未完全合并的更改(即,导致冲突).同样,这可以让你专注于需要你注意的东西 - 合并冲突.

4. staging可以帮助你保留额外的本地文件 - 通常,不应该提交的文件会进入.gitignore或本地变体,.git/info/exclude.但是,有时您希望对无法排除的文件进行本地更改(这不是好习惯,但有时可能会发生).例如,您可能升级了构建环境,现在需要额外的标志或选项以实现兼容性,但如果您将更改提交到Makefile,则其他开发人员将遇到问题.当然,您必须与您的团队讨论并制定更持久的解决方案,但是现在,您需要在工作树中进行更改才能完成任何工作!另一种情况可能是您需要一个临时的新本地文件,并且您不想使用忽略机制.这可能是一些测试数据,日志文件或跟踪文件,或临时shell脚本,以自动化一些测试...无论如何.在git中,您所要做的就是永远不要暂存该文件或进行更改.而已.

5. 分段可以帮助你潜入小变化 - 假设你正处于一个有点大变化的中间,你会被告知一个非常重要的错误,需要尽快修复.通常的建议是在一个单独的分支上执行此操作,但是假设此修复实际上只是一行或两行,并且可以在不影响当前工作的情况下轻松测试.使用git,您可以快速制作并提交该更改,而无需提交您仍在处理的所有其他内容.同样,如果你使用git gui,左下方窗格中的任何内容都会被提交,那么只需确保只有那个更改到达并提交,然后推送!

Answer 2

值得比较一下Git如何处理这个问题--Git让你知道并使用staging-area来处理Mercurial如何处理这个问题.在Mercurial中,您完全按照您的建议工作:您只需运行hg commit并且Mercurial会确定您更改的内容并将其提交.你需要hg add一个新文件,但如果你只是在改变现有文件,那么没有什么特别的事情要做:你改变它们,然后提交,你就完成了.

Mercurial的行为似乎(并且在我看来,已经)更加新用户友好.Git实际上可以让你通过使用获得大部分相同的效果git commit -a.也就是说,你只需添加-a你将使用的其他选项,Git将与Mercurial完全相同.但这是一种拐杖,因为最终,你会发现Git所做的事情是非常难以理解的,除非你知道临时区域.

Hidd3N的答案显示了你可以使用Git的临时区域的多种方法.但是如果你退一步,比较Mercurial和Git,我认为你可以看到更多的真实情况.

请记住,任何版本控制系统(VCS)的工作就是让您检索每一个提交的版本不断.(并且,由于Git和Mercurial都在整个系统的快照上工作,因此在这里很容易比较.有一些旧的VCS一次只能在一个文件上运行:你必须专门检入/提交每个文件Git和Mercurial一劳永逸地创建了所有内容的快照.)这些提交的快照应该永远持续下去,而且永远不会改变.也就是说,它们是只读的.

但是,只读文件不适用于工作.因此,任何VCS 必须在某种程度上/某处具有两个独立的东西:

• 你处理文件的地方:这是你的工作树 ; 和
• 该快照存储的地方:这是你版本的数据库,或存储库,或其他一些字Git的把这些事情对象,而水银具有更复杂的组结构,所以我们只给他们打电话的对象在这里.

Git的对象存储区域有一堆只读对象:实际上,每个文件都有一个,每次提交都有,等等.您可以随时添加新对象,但不能更改任何现有对象.

由于水银表明,没有要求单独的分期区:VCS可使用工作树作为建议提交.当您运行时hg commit,Mercurial打包工作树并从中进行提交.在工作树中进行更改时,您将更改建议的下一个提交.该hg status命令显示您要提交的内容,即:当前提交和工作树之间的不同之处.

但是,Git选择在只读提交和读/写工作树之间插入这个中间区域.此中间区域,暂存区域或索引或缓存包含建议的下一个提交.

首先查看一些提交.此时,您有每个文件的三个副本:

• 一个是在当前提交中(Git总是可以通过名称找到HEAD).这个是只读的; 你无法改变它.它采用特殊的,压缩的(有时是非常压缩的)Git形式.
• 一个是在索引/登台区域.这个与HEAD现在匹配,但可以更改.这是建议进入下一次提交的人.这也是特殊的Git形式.
• 最后一个是在你的工作树中,以普通的形式,你可以在它上面工作.

什么git add做的是从你的工作树复制文件,到临时区域,覆盖的是用来匹配的一个HEAD承诺.

当你跑步时git status,它必须进行两次单独的比较. 一个比较了HEAD对index/staging-area 的提交,看看下一次提交会有什么不同.这是什么to be committed.第二个比较发现index/staging-area和work-tree之间有什么不同.这是什么not staged for commit.

当你运行时git commit -a,Git只根据第二次比较进行复制到登台区域.更确切地说,它运行相当于git add -u.(如果由于某种原因提交失败,它会秘密地使用临时暂存区域,这样您的常规登台区域/索引在提交期间不会受到干扰.其中一些还取决于其他git commit参数.通常情况下这往往是不可见的,至少在你开始编写复杂的提交钩子之前.)

Answer 3

该中转区就像是一个粗略的空间草案，这是在那里你可以git add或版本的文件，要在你的下一个保存多个文件提交（在项目的下一个版本换句话说）。

请注意，您可以将文件的版本复制到暂存区，也可以在提交之前将它们从暂存区中取出，这就是我将其称为草稿空间的原因。

该git add命令的实际作用是将该版本的文件从您的工作目录复制到暂存区。

（这是一个常见的误解，人们可能会在他们的心理模型中认为文件被移动了，但实际上它被复制了。）

将文件的更新版本添加到您的存储库所需的过程：

• 1??它在您的工作目录中编辑。工作目录就像一个工作台，您可以在其中编辑文件、添加新文件和删除文件。
• 2??然后使用git add命令将文件添加到暂存区
• 3??最后在使用git commit命令的时候包含在下一次提交中

能够选择将哪些文件添加到暂存区并包含在提交中的好处在于，您可以通过这种方式更好地组织工作。

您可以添加与一项工作相关的所有更新文件，并且在进行提交时，您可以添加一条提及该工作的消息。

这样你就可以更好地组织你的提交。

该视频以非常简单和直观的方式解释了上述所有内容，因此可能会有所帮助！

ps 另一个小花絮，以防有人好奇暂存区在您的 .git 目录中的真正位置。它由.git 目录中的索引文件表示！