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