git 决定不提交新添加的文件当前内容而是提交添加时的内容背后的理由是什么？
所以，根据我在 Pro Git 中读到的内容，
原来 Git 暂存了一个文件 与运行时完全相同
添加命令。如果你承诺 现在，版本someFile原样 当您上次运行add时 命令是它将如何进入 提交，而不是文件的版本 它会在您的工作目录中查找 当您运行commit时。如果 运行后修改文件添加，你必须运行 再次添加以暂存 文件的最新版本
似乎当您将文件添加到 git 存储库时，要么立即提交，要么在提交之前对同一文件进行任何修改，这些修改将不会保存在该提交中。
这背后的理由是什么？
So, from what I've read in Pro Git,
It turns out that Git stages a file
exactly as it is when you run theaddcommand. If you commit
now, the version ofsomeFileas it was
when you last ran theadd
command is how it will go into the
commit, not the version of the file as
it looks in your working directory
when you runcommit. If
you modify a file after you runadd, you have to runaddagain to stage the
latest version of the file
it seems that when you add a file to your git repository, either you commit right away, or your if you make any modifications to that same file before the commit, those modifications won't be saved in that commit.
What is the rationale behind that?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
git 不跟踪文件，它跟踪更改。因此，当您“添加文件”时，您不是添加文件，而是向该文件添加更改，对于新文件来说是您添加它时的所有内容。因此，如果您在“添加文件”之后但在提交之前进行更改，则还必须添加这些新更改，否则它们将不会被提交。
git doesn't track files, it tracks changes. So when you "add a file", you're not adding the file, you're adding the changes to that file, which in the case of a new file is all its content at the point that you added it. So, if you make changes after "adding the file" but before you commit, you have to add those new changes as well or they won't get committed.
几乎总是，在添加后立即提交是有意义的，这就是为什么
commit有一个-a选项，以及为什么几乎所有其他 VCS 不允许您拆分添加和提交，即使它们在内部是单独的阶段。在某些情况下，单独执行会非常方便。如果有些人不确定是否要保留更改，并且仍在进行试验，他们会使用暂存区作为一种临时提交。我更喜欢所有提交都是可编译的，因此当我准备好提交但遇到一堆编译错误时，有时我会执行
add操作。这让我可以对我所做的更改进行比较，同时修复编译错误，以防万一搞砸了。如果您出于某种原因想要将更改拆分为多个提交，它也非常方便。Almost always, it makes sense to commit immediately after an add, which is why
commithas an-aoption, and why practically every other VCS doesn't let you split the add and commit, even though they are separate stages internally.There are some circumstances where it is very handy to do separately. Some people use the staging area as a sort of temporary commit if they're not sure they want to keep the changes or not, and are still experimenting. I prefer all my commits to be compilable, so I will sometimes do an
addwhen I am ready to commit but have a bunch of compile errors. That lets me do adiffon what I have changed while fixing compile errors in case I mess anything up. It's also very handy if you want to split your changes into multiple commits for whatever reason.它实际上与 git add 处理非新文件的方式非常一致。
这会添加文件与您执行 git add 时的情况相同。比如说，在 svn 中，您甚至不会执行添加操作，因为
svn add仅适用于新文件。因此，这是一个额外的步骤（除非您像其他人所说的那样使用 git commit -a ），但它为您提供了更大的灵活性，可以在同一个文件中仅提交一些更改，而让其他更改保持未提交。一旦您熟悉了 git，您可能会因为这个原因而爱上 git add -p 命令。 :)It's actually very consistent with the way
git addworks for non-new files.This adds the file as it looked at the time you did the git add. In, say, svn, you wouldn't even do the add because
svn addis only for new files. So it's one extra step (unless you usegit commit -aas someone else said) but it gives you a lot more flexibility, to commit only some changes and leave others uncommitted, within the same file. Once you get comfortable with git, you may fall in love with thegit add -pcommand for exactly this reason. :)