Несмотря на то, что GIT НЕ хранит файловые дельты, вы все равно можете выполнить откат к предыдущим версиям файлов (неограниченное количество раз?)

Я читал, что Git не хранит файловые дельты. Если это правда, как он поддерживает откат файла к предыдущим версиям? Если он хранит весь файл, пространство хранилища на диске должно увеличиться до неуправляемо большого размера. Поддерживает ли Git откат файлов и diff (s) до версии файла 1? Поддерживает ли оно даже концепцию управления версиями в отношении файлов? Это (я считаю) важно для моего понимания VCS / DVCS и моих потребностей. Мне нужно сравнить то, что я собираюсь проверить, с предыдущими версиями.

Git не выбрасывает информацию самостоятельно *. Все предыдущие версии каждого файла всегда доступны для возврата, различий, проверок и так далее.

Целое дерево против отдельных файлов

Возможно, вы пытаетесь согласовать идею доступа к старой версии отдельного файла по сравнению с тем фактом, что модель истории Git сфокусирована на всем дереве. Управление версиями для всего дерева требует немного больше работы, чтобы увидеть (например) версию, foo.cсуществовавшую десять foo.cизменений назад по сравнению с десятью изменениями всего дерева назад:

# 10 foo.c-changes ago
git show $(git rev-list -n 10 --reverse HEAD -- foo.c | head -1):foo.c

# 10 whole-tree-changes ago
git show HEAD~10:foo.c

Преимущества древовидной ориентации, в основном возможность просматривать коммиты как единицу взаимозависимых изменений, внесенных в различные части всего дерева, в целом значительно перевешивают дополнительную типизацию (которая может быть уменьшена с помощью псевдонимов, сценариев и т. Д.) И время процессора копаться в прошлых коммитах.

Эффективность хранения

Когда в систему попадает новый объект (например, файл с ранее невидимым содержимым), он сохраняется с простым (zlib) сжатием как «свободный объект». Когда накапливается достаточное количество незакрепленных объектов (в зависимости от параметра gc.autoконфигурации; или когда пользователь запускает git gc или одну из команд упаковки более низкого уровня), Git собирает много незакрепленных объектов в один «файл пакета».

Объекты в файле пакета могут храниться как простые сжатые данные (такие же, как незакрепленный объект, просто связанный с другими объектами), так и как сжатые дельты с некоторыми другими объектами. Дельты могут быть объединены в цепочку с настраиваемой глубиной ( pack.depth) и могут создаваться для любого подходящего объекта ( pack.windowконтролирует, насколько широко Git ищет лучшую дельта-базу; версию исторически несвязанного файла можно использовать в качестве базы, если это приведет к хорошая дельта компрессия). Широта, которую конфигурации глубины и размера окна дают механизму дельта-сжатия, часто приводят к лучшему дельта-сжатию, чем простое сжатие «diff» в стиле CVS «одна версия против следующей / предыдущей версии».

Именно это агрессивное дельта-сжатие (в сочетании с обычным сжатием zlib) часто позволяет Git-репозиторию (с полной историей и несжатым рабочим деревом) занимать меньше места, чем одна проверка SVN (с несжатым рабочим деревом и нетронутой копией).

См., Как Git хранит объекты и разделы Packfile в Git Community Book . Кроме того , мерзавец пачка объектов страницы руководства .

_{* Вы можете сказать Git выбросить коммиты «переписав историю» и с помощью таких команд, как git reset , но даже в этих случаях Git «зависает» на недавно отмененных коммитах на некоторое время, на тот случай, если вы решите, что они вам нужны. Смотрите git reflog и git prune .}

Это можно прочитать на той же странице:

...

Следовательно, Git явно не записывает отношения редакции файла на любом уровне ниже дерева исходного кода.

...

Немного дороже изучить историю изменений одного файла, чем весь проект. Чтобы получить историю изменений, влияющих на данный файл, Git должен просмотреть глобальную историю и затем определить, изменило ли каждое изменение этот файл. Однако этот метод изучения истории позволяет Git с одинаковой эффективностью создавать единую историю, показывающую изменения в произвольном наборе файлов. Например, подкаталог исходного дерева и связанный глобальный заголовочный файл - очень распространенный случай.

...

Таким образом, вы можете вернуться к предыдущим версиям файла и сравнить два файла.

Git на самом деле сохраняет дельты файлов, но сохраняет их как дельту всего дерева файлов.

Чтобы увидеть различия между версиями, выполните одно из следующих действий:

1. git diff - показывает различия между последней зарегистрированной версией и файлами, которые были изменены, но не были git addзапущены на них.
2. git diff --cached - показывает различия между предыдущей версией и тем, что все файлы были git addзапущены, но не были зафиксированы
3. git diff commitid - показать различия между текущим рабочим каталогом и предыдущим коммитом, как указано в commitid
4. git diff commita..commitb - показывает различия между двумя коммитами, a и b. Коммиты также могут быть символическими именами, такими как ветви или теги.