git history data для больших проектов

Question

Я новичок в Git и пытаюсь понять принципы.Как я понимаю, в Git каждый файл хранится полностью согласно Git Book , а также согласно этой записи .Однако git book также указывает git gc, который сжимает двоичные файлы и вычисляет diff для текстовых файлов, и это утверждение, кажется, противоречит первому пункту, что git хранит полные файлы.

1) Может кто-нибудь объяснить, какой из них правильный?Если git gc вычисляет частичные различия, и если он запускается через долгое время, будет ли это гарантировать, что все различия созданы из базовых версий для всех ветвей?Означает ли это, что git gc не запускается регулярно на большом количестве вычислительных ресурсов?

2) Рассматривая такие проекты, как Android, где имеется огромное количество исходных и ресурсных файлов, кажется, что это означает, что git собираетсявзрываться с каждым коммитом.Когда разработчики извлекают исходный код Android, не займет ли это много места, если он вытянет всю историю для всех исходных и двоичных файлов?Я что-то здесь упускаю?Как это устойчиво в долгосрочной перспективе?

Answer 1

Git - это модная файловая система с адресацией содержимого. Условно , в нем хранится полное содержимое каждого файла в каждой ревизии, и каждый большой двоичный объект (содержимое файла) имеет свой символ, которым его можно получить. Под капотом у git фактически есть возможность сохранять файл как diff для аналогичного файла (обычно это предыдущая версия, но это не обязательно должно быть), но это происходит полностью на самом низком уровне того, как git хранит файлы , Мало того, что пользователям git не нужно думать об этом, даже большинству инструментов git не нужно думать об этом.

Что касается вопроса о размере, , потому что в "git filesstem" есть различные формы сжатия, и, поскольку они довольно эффективны, каталог .git, содержащий всю историю проекта обычно меньше, чем единичная проверка кода , пока проект не достигнет сотен тысяч коммитов.

Если хранилище становится неуправляемо большим, можно (с помощью таких инструментов, как git graft) разделить историю проекта на разные репозитории по линиям новой / древней истории, активным / архивным ветвям или другим такие вещи.

Answer 2

Способ git gc вычисления различий для хранения не обязательно связан с историей файла. На самом деле, я помню, как где-то читал, но не могу найти ссылку на данный момент, так как он может выбрать более последние ревизии для "базы", потому что это те, которые вы, скорее всего, сможете проверить , Если у вас 10 000 ревизий и вы проверяете последние версии, вы не хотите применять 10 000 различий к ревизии 1, чтобы получить нужную версию.

В некоторых операциях git gc запускается автоматически. pull является одним из них, так что вы вряд ли продержитесь слишком долго. Ничто не мешает вам запускать его после каждого коммита, если вы так склонны. По сути, это то, что делают другие системы контроля версий за кулисами, и это одна из главных причин, почему git такой быстрый.

Answer 3

git gc используется для очистки / сжатия незакрепленных объектов в хранилище.Это делается путем упаковки объектов (каждое полное состояние файла / дерева / фиксации).Различия могут быть созданы из предыдущего файла или могут быть из файла, совершенно не связанного с ним, но имеют похожее содержимое git.

Чтобы ответить на вопрос 2, как указано выше, git собирает объекты.Хотя концептуально существует полная копия каждого файла, под капотом они упаковываются при запуске gc.Что касается хранения бинарных файлов, контроль версий в целом не лучший выбор.