Может кто-нибудь объяснить разницу между отслеживанием контента, используемым в Git, и отслеживанием файлов, используемым в других SCM

Question

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

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

Может кто-нибудь объяснить, почему это так? Я не заметил ничего особенного в этом отношении по сравнению с SVN. Чего мне не хватает?

Answer 1

Git хранит три элемента данных отдельно :

• содержимое хранится в объектах BLOB-объектов
• история сохраняется в объектах фиксации
• структура хранится в древовидных объектах

Следствием этого является то, что если у вас одни и те же данные в нескольких файлах, git должен хранить их только один раз, потому что структура (которая содержит каталоги и файлы) толькодолжен указывать на один объект содержимого.

Аналогично, если файл не изменяется от версии к версии, git должен хранить этот файл только один раз.Несколько объектов истории указывают на один и тот же контент.

Некоторые из видимых для пользователя преимуществ заключаются в том, что git blame очень хорошо видит перемещение кода по файлам , особенно если вы говорите, что он выглядит очень серьезно сgit blame -C.Это также одна из причин, почему git такой компактный и быстрый, структура очень проста, обходится очень дешево и не повторяется.

Одним из недостатков является то, что git не хранит копии файлов и переименовывает, он просто догадывается, а иногда и ошибается.

Эта запись в блоге обеспечивает достаточно хорошо усвоенное, но все же подробное обсуждение того, что отслеживание контента покупает git.Если вы хотите узнать больше, вы можете посмотреть Google Tech Talk Линуса на Git или прочитать стенограмму .

Answer 2

Единственная информация, которую Git хранит от одной ревизии к следующей, - это состояние (имена и содержимое) файлов в каждой ревизии. В редакции A этот файл содержал это содержимое, а в редакции B этот файл содержал другое содержимое. Git не волнует как файлы, полученные из точки А в точку Б, будь то редактирование, или переименование, или разрешение конфликтов, или слияние осьминога.

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

Одним из следствий этого является то, что всякий раз, когда Git нужно выяснить, что произошло между ревизиями A и B (например), он должен проработать детали в тот момент, когда вы об этом просите. Даже для простого сравнения, в то время как некоторые инструменты могут просто показать внутренне сохраненный дифференциал, Git сравнивает файлы в ревизии A и B и регенерирует разницу по запросу. Для переименований Git замечает, что только что появился новый файл, и ищет похожие файлы в предыдущей ревизии, чтобы угадать, был ли файл переименован или нет.

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