Поддерживает ли GIT также такую историю всех проверок в ветви и файлов, изменяемых / добавляемых / удаляемых при каждой регистрации?
Нет: модель Git совершенно другая.
Другими словами: предположим, сегодня в GIT в любой ветке я регистрирую / фиксирую некоторые изменения файла.
Git не хранит изменения .Git магазины совершает .Каждый коммит представляет собой полный снимок каждого файла , целого и неповрежденного, с содержимым, которое имел каждый такой файл на момент совершения коммита.
Точнее, коммит - это объект- это термин Git, но мы можем использовать его и здесь, в общем, - идентифицируемый уникальным хеш-идентификатором, таким как 5d826e972970a784bd7a7bdf587512510097b8c7 (это хеш-идентификатор коммита в Git-репозитории для Git), который:
- содержит некоторые метаданные, такие как имя человека, совершающего фиксацию, адрес электронной почты и временную метку;
- содержит идентификатор хеша его непосредственной предшествующей фиксации (ий) - обычно только один такой;
- содержит сообщение журнала, которое вы предоставляете;и
- содержит хеш-идентификатор объекта Git, представляющего снимок.
Дополнительные уровни косвенности (коммиты содержат хеш-идентификаторы деревьев, которые содержат хеш-идентификаторы BLOB-объектов, содержащих файлы.'содержание) позволяет Git повторно использовать неизмененные файлы в течение нескольких коммитов.Каждый объект Git на 100% доступен только для чтения, так что после фиксации все содержимое файлов сохраняется на все время (или, по крайней мере, до тех пор, пока сам коммит не будет удален, что довольно сложно).
Git представляет фиксирует как изменения, но для этого git log начинается с последнего коммита, идентифицируемого его хеш-идентификатором, который вы должны каким-то образомпредоставлять.(Вы можете сделать это по необработанному хэш-идентификатору, но это уродливо. Мы вернемся к этому через минуту.) Это последний коммит, потому что Git теперь работает в обратном направлении , используяидентификатор хеша предшественника, сохраненный в этом коммите:
... <-F <-G <-H <-- start here at H
Коммит H - это полный снимок всех файлов.Так же, как и G, H предшественник.Git извлекает два коммита, сравнивает их и распечатывает разницу между ними, чтобы показать вам, что произошло в H.
Теперь, когда Git показал H, он можетвернитесь к G.Чтобы показать, что произошло в G, Git извлекает своего предшественника F, извлекает G, сравнивает их и печатает разницу .
Команда git log - это командатот, который делает это ходьбой назад.Он показывает сообщение журнала и, с помощью -p, также выполняет извлечение-и-разность.
Команда git show, представленная с идентификатором хэша, печатает сообщение журнала и выполняет одну обратную прогулку.-step-and-diff и затем останавливается.
Идентификаторы хеша здесь, конечно, ужасны и совершенно не подходят для обычного использования человеком.В отличие от номеров версий SVN, между любыми двумя хэш-идентификаторами фиксации нет никакой связи.Вы не должны запомнить их.Вместо этого Git предлагает вам два основных способа запомнить их Git :
Имена тегов хранят идентификатор хеша более или менее постоянно.Учитывая коммит, который является финальной версией, вы можете пометить его как таковой.Никто никогда не изменит, какой коммит является релизом v2.20.0, поэтому вы можете пометить 5d826e972970a784bd7a7bdf587512510097b8c7 именем v2.20.0 и больше никогда не вспоминать большой уродливый идентификатор хеша.
Ветвь names - которую мы можем отличить от branch , хотя это немного сложно - также храните хэш-идентификатор.Однако ключевое отличие от тега заключается в том, что когда вы находитесь на ветке и делаете новый коммит, Git автоматически обновляет имя ветви, чтобы сохранить новый хеш-код нового коммита.
Давайте снова посмотрим на этот более ранний чертеж и добавим название ветви, master:
... <-F <-G <-H <-- master (HEAD)
Имя master содержит слово HEADприкреплен к нему.Это означает, что это наша текущая ветвь .
Let 'Идем дальше и делаем новый коммит сейчас (с обычным бредом с изменением файлов и git add и так далее).Git собирает наше лог-сообщение, навсегда замораживает все содержимое файлов, создает объект дерева для их запоминания и создает объект фиксации для хранения метаданных, таких как хеш-идентификатор commit H, хеш-идентификатор нового дерева,лог сообщение мы ввели и тд.Этот новый объект коммита получает новый большой уродливый хеш-идентификатор, который мы будем называть I вместо того, чтобы угадывать его. parent для I будет H:
...--F--G--H <-- master (HEAD)
\
I
Как шаг last нашего git commit, Git теперь записывает фактический хэш-идентификаториз I в имя master, где HEAD прикреплено:
...--F--G--H
\
I <-- master (HEAD)
Так что теперь, если мы попросим Git показать нам master, Git извлечет I, покажет *Лог-сообщение 1130 *, извлеките H, сравните его с извлеченным I и покажите нам разницу от H до I - без необходимости ввода каких-либо хеш-идентификаторов.
Обратите внимание, что если мы прикрепим новое имя ветви develop к H перед фиксацией и сделаем наш HEAD, то новый коммит I перейдет в новую ветку вместо:
...--F--G--H <-- master
\
I <-- develop (HEAD)
Коммит произошел в точно так же .Идентификатор хеша может даже быть точно таким же (хотя для этого требуется, чтобы мы выполняли фиксацию в ту же секунду, поскольку идентификаторы хеша кодируют метки времени внутри коммитов).Изменилось , в какое имя ветки Git записал новый хэш-идентификатор.
Вот что такое ветви Git: это подвижные указатели, указывающие на коммиты.Это совершает , что имеет значение.Имена ветвей - это просто простые способы получения хеш-идентификаторов коммитов, которые автоматически перемещаются по мере нашей работы.
Каждый коммит представляет собой полный снимок, и важны именно хеш-идентификаторы.Имена только для того, чтобы найти хэш-идентификаторы.Большая часть остальной странности Git, когда вы приехали из SVN или Clearcase, связана с этими двумя фактами.(Большая часть остального происходит из-за индекса в Git, который я не буду здесь описывать.)