我终于开始学习git了，我有点困惑。据我所读，并且可能已经被误解了，在对文件进行更改（在您的IDE中本地保存文件？）之后，您必须先进行“ git add”操作，然后再进行“ git commiting”操作。
当我在工作目录中“ git add”所有文件时，进行更改并将其保存在ide中，然后进行“ git commit”，所有更改都将被提交。为什么需要在保存和提交之间使用“ git add”进行重新设置？似乎没有什么区别，我很困惑为什么我读到你需要考虑到它似乎没有什么区别。抱歉，如果这是重复的话，我确实找到了并且找不到我的问题的答案。
哦，我也知道我是否要创建一个新文件，因为尚不知道该文件是否需要添加“ git add”，但我不知道何时要更改文件已经添加了。
为此，我的测试是运行“ git add”来更改文件并保存，然后尝试进行提交以查看它是否在没有新的“ git add”的情况下注册更改，因为它会输出一条消息通知我更改取得了。我一定在我的理解中缺少一些东西。感谢您的帮助。
答案 0 :(得分：4)
某些IDE为您执行git add。您的名字可能就是其中之一，因为您没有命名，所以无法告诉您。
某些IDE 不为您执行git add。在这种情况下，您必须自己做。
哦，我也知道我是否要创建一个新文件，因为尚不知道该文件是否需要添加“ git add”，但我不知道何时要更改文件已经添加了。
在我看来，您的心理模型与Mercurial的实际模型相匹配。在Mercurial中，您使用hg add告诉Mercurial：此文件应处于提交状态。从那时起，hg commit在您的工作中使用该文件的版本，树进行新的提交。
（工作树是您进行工作的地方。这与只读的提交相反：您实际上无法更改存储在提交中的文件。它们通常也经过高度压缩，并且一种仅对版本控制系统有用的表格。Mercurial和Git都是如此。）
Git与Mercurial不同。当Git进行新的提交时，Git 不会使用工作树中的内容。 Git会使用它调用的内容，而不同（取决于谁在进行调用）， index < / em>，临时区域，甚至是缓存。对于使用Mercurial或其他几乎所有版本控制系统的人来说，这种特殊的策略显得古怪而疯狂。但这就是Git的工作方式。
当Git 提取提交时，它将提交的内容复制到索引和工作树中。索引中每个文件的版本都与提交中只读存储的版本匹配；但是索引中的副本可以被覆盖。然后，Git使用索引副本（现在与提交副本匹配）来以正常的未压缩格式制作工作树副本，以便您可以使用它。
当您运行git add file时，Git会将正常的未压缩工作树文件复制回索引（又称为暂存区）。 替换该文件的先前版本，git commit将提交索引版本，该索引版本现在与工作树版本匹配。
由于Git根据索引中的内容进行提交，因此您（或您的IDE）必须不断将对工作树所做的任何修改复制到索引中。索引版本已经采用特殊的，仅Git的压缩格式，这一事实使git commit的运行速度非常快-付出了所有这些额外复制步骤的代价。在具有大量文件的大型存储库中，这实际上有很大的不同：hg commit可能需要秒，而git commit几乎是瞬时的。
（在一个小型存储库中，Git的幻想简直太烦人了。但是，您可以使用索引来玩一些特殊的技巧，以便提交与先前的提交和不同的东西工作树！在某些情况下，这实际上是非常有用的。它也非常令人困惑，并且如果可以避免的话，不要随便做些。）