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

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

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

Всего-дерево против индивидуальных файлов

То, что вы пытаетесь согласовать, – это идея доступа к старой версии отдельного файла по сравнению с тем фактом, что модель истории Git ориентирована на все дерево. Версии целых деревьев требуют немного больше работы, чтобы увидеть (например) версию foo.c поскольку она существовала десять foo.c -changes ago против десяти изменений целых деревьев назад:

 # 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 конфигурации gc.auto или когда пользователь запускает git gc или одну из команд уплотнения нижнего уровня), Git собирает много незакрепленных объектов в один «пакетный файл».

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

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

См. Раздел « Как объекты Git Stores» и «Packfile» в «Книге сообщества Git» . Также используется man страница git pack-objects .

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

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

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

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

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

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

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

  1. Git diff – показывает различия между последними проверенными версиями и файлами, которые были изменены, но не git add в них git add run.
  2. Git diff –cached – показывает различия между предыдущей версией и всеми файлами, которые имели git add run, но не были зафиксированы
  3. Git diff commitid – показать различия между текущим рабочим каталогом и предыдущим фиксацией, указанным с помощью commitid
  4. Git diff commita..commitb – показывает различия между двумя коммитами, a и b. Коммиты также могут быть символическими именами, такими как ветви или теги.
  • Как использовать Терминал для рекурсивного удаления всех .svn-папок?
  • Какой значок Dropbox предназначен для имени идентификатора значка Overlay?
  • Git vs SVN: эффективность хранения веб-сайта
  • Сохраняют ли символьные файлы ссылок SVN?
  • TortoiseSVN - Иконки не отображаются
  • Давайте будем гением компьютера.