Является ли область размещения Git просто индексом?
В книге Pro Git говорится, что промежуточная область была просто списком или индексом, в котором говорится, какие файлы будут зафиксированы, когда git commit сделано, и теперь имя index более известен как "область подготовки".
Но если мы изменим файл foo.txt это уже является частью репо, и использовать git add foo.txt чтобы подготовить его и снова изменить файл, теперь файл является "подготовленным" и "измененным" (как видно из git status), и если мы сделаем коммит, "постановочная" версия войдет в коммит. Второе редактирование не пойдет.
Так как же "промежуточная область" отслеживать, каким было первое редактирование, если это просто индекс - список файлов?
6 ответов
Индекс - это представление вашего рабочего каталога, которое готово к фиксации. Его можно рассматривать как состояние предварительной фиксации и не так просто, как "список файлов". Когда вы делаете git addфайл (с изменением) добавляется в индекс, и более новые изменения не будут видны, пока вы не добавите их тоже.
index это как корзина выполненной работы. В любой момент вы можете add (частично) заполненный файл в этой корзине, и он заменит предыдущую копию вашей текущей копией, так что, когда вы наконец решите commit он будет использовать содержимое этой корзины (текущий index) создать коммит.
Кроме того, ваш ранее add в репо будет создан объект BLOB-объекта, который может быть найден при необходимости в различных журналах. Через некоторое время (30 дней +) он исчезнет с gc,
Так как же "промежуточная область" отслеживать то, что было первым редактированием, если это просто индекс - список?
Индекс - это список имен и указателей на контент. В книгах это номера страниц. В индексе Git это идентификатор объекта в базе данных объектов репозитория.
Вот что такое индекс Git, список указателей содержимого, индексированный по пути.
git add для некоторого пути в основном
sha=`git hash-object -w path/to/it`
git update-index --cacheinfo 100644,$sha,path/to/it
Кроме git add проверяет наличие исполняемых файлов и использует 100755 для них, и рекурсивно добавляет и проверяет ваши .gitignoreи все остальное, что кажется наиболее удобным. Это удобная команда для добавления содержимого в объект db и обновления индекса.
Это индекс, но список деревьев изменений, а не файлов напрямую. Смотрите другой тип объектов git handle.
индекс на самом деле не является списком файлов, которые мы видим в проекте. это список s, которые будут присутствовать в снимке, который мы собираемся зафиксировать следующим.
считайте, что это файл, содержащий сжатое содержимое определенного файла, напримерfoo.txtв конкретный момент. (подробнее об этом здесь )
когда вы добавляете файл в промежуточную область, например,git add foo.txtдля этого файла генерируется новый файл, содержащий содержимое файла на момент его добавления в промежуточную область. мы можем увидеть это, используяgit ls-file -s. мы увидим что-то вроде этого:
100644 9cdf71db89dabc03936d7e685d812272e8976274 0 foo.txt
поэтому, если мы внесем какие-либо изменения, предыдущий контент все равно будет храниться в иindexфайл все еще имеет ссылку на него (т.е. его хэш SHA19cdf71db89...).
(Настоящийblobхранится в.git/9c/df71db89...и чтобы увидеть его содержимое, мы можем использовать git cat-file -p 9cdf71db89da)
Промежуточная область - это не просто список и не индекс, в котором говорится, какие файлы будут зафиксированы при выполнении фиксации git.
Если бы это было так, т.е. простой список, git add никогда не мог работать так, как рекламируется.
Скорее, git addдолжен сохранять содержимое файла во время подачи команды добавления. Таким образом, он делает снимки файлов, а затем помещает эти снимки в промежуточную область (также называемую "индекс", что, по моему мнению, на самом деле является довольно плохим выбором для имени).
Так что да, на самом деле утверждение книги вводит в заблуждение и сбивает с толку. Но в этом нет ничего удивительного. Большая часть документации git сбивает с толку и плохо продумана.
Давай, отметь меня. Я уверен, что прав в этом.