将git add .或git add <filename>添加到临时区域有什么意义？为什么不只是git commit -m "blabla"？
我不了解临时区域的价值。
答案 0 :(得分：8)
git中有多种staging用法。下面列出了一些： -
分段可帮助您将一个大型更改拆分为多个提交 - 让我们说您正在进行大量更改，涉及大量文件和相当多的不同子任务。你实际上没有提交任何这些 - 你在＆＃34;就像他们所说的那样，并且你并不想考虑以正确的方式分割提交。 （并且你足够聪明，不要让整个事情按照大提议！）。 现在，所有更改都经过测试和工作，您需要在几个干净的提交中正确提交所有这些，每个提交都集中在代码更改的一个方面。 使用索引，只需暂存每组更改并提交，直到不再有待更改。如果你也适用于git gui，你也可以使用git add -p，或者使用更新的git，git add -e。
分段有助于审核变更 - 分段可帮助您“检查”＃34;审核复杂提交时的个别更改，并专注于尚未通过审核的内容。让我解释。在您提交之前，您可能会使用git diff查看整个更改。如果您在审核时更改每个更改，您会发现您可以更好地专注于尚未上演的更改。 git gui在这里很棒。它的两个左窗格分别显示了未分级和分阶段的更改，您只需单击文件名左侧的图标即可在这两个窗格之间移动文件（stage / unstage）。更好的是，您甚至可以对文件进行部分更改。在git gui的右侧窗格中，右键单击您批准的更改，然后选择＆＃34; stage hunk＆＃34;。只是改变了（不是整个文件）现在上演了;事实上，如果同一个文件中还有其他未分阶段的更改，您会发现该文件现在显示在左上窗格和左下窗格中！
分段在合并发生冲突时有帮助 - 合并发生时，干净地合并的更改会在暂存区域和工作树中更新。只有当你执行git diff时，或者在git gui的左上方窗格中，才会显示未完全合并（即导致冲突）的更改。同样，这可以让你专注于需要你注意的东西 - 合并冲突。
分段可帮助您保留额外的本地文件 - 通常，不应提交的文件会进入.gitignore或本地变体.git / info / exclude。但是，有时您希望对无法排除的文件进行本地更改（这不是好习惯，但有时可能会发生）。例如，您可能升级了构建环境，现在需要额外的标志或选项以实现兼容性，但如果您将更改提交到Makefile，则其他开发人员将遇到问题。当然，您必须与您的团队讨论并制定更持久的解决方案，但是现在，您需要在工作树中进行更改才能完成任何工作！另一种情况可能是您想要一个临时的新本地文件，并且您不想打扰忽略机制。这可能是一些测试数据，日志文件或跟踪文件，或临时shell脚本，以自动化一些测试...无论如何。在git中，您所要做的就是永远不要暂存该文件或进行更改。那就是它。
分期可以帮助您潜入小变化 - 让我们说您正处于一个有点大变化的过程中，并且您被告知了一个非常重要的变化需要尽快修复的bug。通常的建议是在一个单独的分支上执行此操作，但是让我们说这个修复程序实际上只是一两行，并且可以在不影响当前工作的情况下轻松测试。使用git，您可以快速制作并提交该更改，而无需提交您仍在处理的所有其他内容。同样，如果您使用git gui，左下方窗格中的任何内容都会被提交，那么只需确保只有更改到达并提交，然后按下！
答案 1 :(得分：7)
值得比较一下Git如何处理这个问题--Git让你了解并使用staging-area来了解Mercurial如何处理这个问题。在Mercurial中，您完全按照您的建议工作：您只需运行hg commit，Mercurial会找出您更改的内容并进行提交。您必须hg add 新的文件，但如果您只是更改现有文件，则没有什么特别的事情要做：您更改它们，然后提交，就完成了。
Mercurial的行为似乎（并且在我的观察中）已经变得更加新用户友好了。通过使用git commit -a，Git实际上可以让您获得大部分相同的效果。也就是说，您只需将-a添加到您将使用的任何其他选项中，Git将与Mercurial完全相同。但这是一种拐杖，因为最终，你会发现Git所做的事情是非常难以理解的，除非你知道临时区域。
Hidd3N's answer显示了许多可以使用Git临时区域的方法。但是如果你退一步，比较Mercurial和Git，我认为你可以看到更多的真实情况。
请记住，任何版本控制系统（VCS）的任务是让您检索每个提交的版本 。 （并且，既然Git和Mercurial都在整个系统的快照上工作，那么它们很容易在这里进行比较。有一些旧的VCS一次只能在一个文件上运行：你必须专门检查-in / commit每个单独的文件.Git和Mercurial一起创建所有内容的快照。）这些提交的快照应该永远持续，并且永远不会改变。也就是说，它们是只读。
但是，只读文件不适用于工作。因此，任何VCS 必须以某种方式/某处，两个单独的东西：
Git的对象存储区域有一堆只读对象：实际上，每个文件都有一个，每次提交都有，等等。您可以随时添加 new 对象，但不能更改任何现有对象。
正如Mercurial所示，单独的暂存区域没有要求：VCS可以使用工作树作为建议的提交。当您运行hg commit时，Mercurial会打包工作树并从中进行提交。在工作树中进行更改时，您将更改建议的下一个提交。 hg status命令显示您要提交的内容，即：当前提交和工作树之间的任何不同。
首先查看一些提交。此时，您有每个文件的三个副本：
HEAD找到）。这个是只读的;你无法改变它。它采用特殊的，压缩的（有时是非常压缩的），仅限Git的形式。HEAD，但可以更改。它是建议进入 next 提交的人。这也是特殊的Git形式。 git add做的是将文件从工作树复制到暂存区域，覆盖用于匹配HEAD提交的文件。
当你运行git status时，它必须进行两次单独的比较。一次将HEAD提交与索引/登台区域进行比较，看看是什么＆＃39; s在下一次提交中会有所不同。这就是to be committed。第二个比较发现索引/临时区域和工作树之间有什么不同。这就是not staged for commit。
当您运行git commit -a时，Git只根据第二次比较执行复制到暂存区域。更确切地说，它运行相当于git add -u。 （如果由于某种原因提交失败，它会秘密地使用临时登台区域执行此操作，以便您的常规登台区域/索引在提交期间不受干扰。其中一些取决于在其他git commit参数上也是如此。通常情况下，这往往是不可见的，至少在你开始编写复杂的提交钩子之前。）
答案 2 :(得分：3)
staging area就像草稿空间，在这里您可以git add版本的文件或要保存在下一个 commit < / strong>（换句话说，就是项目的下一版本）。
请注意，您可以将文件的版本复制到暂存区中，也可以在进行提交之前将其保存在out of the staging area中，这就是为什么我将其称为草稿空间。
git add命令的实际作用是将文件的该版本从工作目录复制到暂存区。
（这是一个常见的误解，人们可能会在其心理模型中认为文件已移动但实际上已被复制。）
将文件的更新版本添加到存储库所需的时间：
git add命令将文件添加到暂存区域git commit命令时，它会包含在下一次提交中能够选择要添加到登台区域并包含在提交中的文件的好处是，您可以通过这种方式更好地组织您的工作。
您可以添加与一件作品相关的所有更新文件，并且在进行提交时可以添加一条提及该作品的消息。
这样，您可以更好地组织提交。
This video?以一种非常简单和直观的方式解释了以上所有内容，因此可能会有帮助！
p.s。另一个小窍门，以防万一有人好奇过渡区域确实在您的.git目录中。它由您的.git目录中的 index file 表示！
答案 3 :(得分：1)
如果您认为暂存是无用的，那么您也可能意识到git和软件开发的全部功能.Staging意味着您希望将这些文件提交到当前分支。有时候您可能不想提交某些文件，因此这些文件不会被提交以进行提交。
例如： - 某些特定于您系统的默认配置，因此您可能不希望将这些配置文件提交到每个人都使用这些配置文件的分支。 我希望它能清除你的怀疑！ ： - ）
答案 4 :(得分：0)
Microsoft Word具有您建议的方法。文档中所做的任何更改都将一起保存。没有暂存区。你别无选择。简单但不灵活。
但是Git给您更多的力量。您可以选择何时以及如何记录所做的更改。复杂，但功能强大。从根本上讲：Git用户是程序员，我们很聪明并且有能力，我们想要这种灵活性。
弗雷迪（Freddie）写了一些出色的歌词。在已经将它们写出之后，他如何保存它们在四个单独的提交中？
妈妈，刚刚杀了一个人
把枪对准他的头
拉动我的扳机，现在他死了
妈妈，生活才刚刚开始
登台区域使他可以执行此操作。这是类似于软件开发的工作流程。