Некоторые IDE делают git add для вас. Ваш может быть одним из них - мы не можем сказать, так как вы не назвали его.
Некоторые IDE не делают git add для вас. В этом случае вы должны сделать это самостоятельно.
О, также, я бы понял, если бы я делал новый файл, так как это нужно было бы добавить с помощью "git add", так как это еще не известно, но я не понимаю, когда я меняю файлы, которые я уже добавлено.
Мне кажется, что ваша ментальная модель соответствует реальной модели Mercurial. В Mercurial вы используете hg add, чтобы сообщить Mercurial: этот файл должен быть в коммитах. С этого момента hg commit использует версию этого файла в вашем рабочем дереве для сделать новый коммит.
(Рабочее дерево - это то место, где вы выполняете свою работу. Это в отличие от коммитов, которые доступны только для чтения: вы буквально не можете изменять файлы, хранящиеся в коммитах. Они также обычно сильно сжаты, и в форма, полезная только для системы контроля версий. Это верно как для Mercurial, так и для Git.)
Git отличается от Mercurial. Когда Git делает новый коммит, Git не использует то, что находится в рабочем дереве. Вместо этого Git использует то, что он вызывает, по-разному (в зависимости от того, кто выполняет вызов), index , область подготовки или даже кеш . Эта конкретная тактика кажется дурацкой и сумасшедшей для всех, кто использовал Mercurial или, ну, почти любую другую систему контроля версий, но именно так работает Git.
Когда Git извлекает коммит, он копирует содержимое коммита в индекс и рабочего дерева. Версия каждого файла в индексе соответствует версии, сохраненной только для чтения в коммите; но копия в индексе может быть перезаписана . Затем Git использует индексную копию (которая теперь совпадает с копией коммита), чтобы сделать копию рабочего дерева в ее обычном несжатом формате, чтобы вы могли работать с ним.
Когда вы запускаете git add <em>file</em>, Git копирует обычный, несжатый файл рабочего дерева обратно в индекс (он же staging-area). заменяет предыдущую версию этого файла, а git commit фиксирует версию индекса, которая теперь соответствует версии рабочего дерева.
Поскольку Git делает коммиты из того, что находится в индексе , вы или ваша IDE должны постоянно копировать любые изменения, сделанные в рабочем дереве, в индекс. Тот факт, что индексная версия уже находится в специальном сжатом формате Git-only, заставляет git commit работать очень быстро - за счет необходимости выполнения всех этих дополнительных шагов копирования. В большом хранилище с большим количеством файлов это действительно имеет огромное значение: hg commit может занять секунд , в то время как git commit почти мгновенно.
(В небольшом репозитории причудливость Git в основном просто раздражает. Однако вы можете использовать специальные трюки с индексом, чтобы зафиксировать что-то, что отличается как от предыдущего коммита, и , что в Дерево работы! Это действительно чрезвычайно полезно в некоторых случаях. Это также ужасно запутанно, и не нужно делать что-то случайно, если вы можете избежать этого.)