MyTetra Share
Делитесь знаниями!
Git: проверка состояния репозитария, поддержание репозитария в рабочем состоянии
07.08.2018
11:51
Текстовые метки: git, gc, garbage collector, сборка мусора, проверка, ошибки, состояние
Раздел: Компьютер - Программирование - Системы контроля версий (VCS) - Git

Обеспечение эффективной деятельности

Размер репозитории git зависит от сжатия сохранённой истории информации. Сжатие не даёт занять репозиторию слишком много места на диске и в памяти. Сжатие не выполняется автоматически. Поэтому вы должны периодически запускать git-gc(1) :

$ git gc 


для повторения сжатия архива. Это может занять очень много времени, поэтому вы, возможно, предпочтете запустить git-gc, тогда, когда это вам не будет мешать работать.

Проверка репозитория


Команда git-fsck(1) запускает ряд логических самопроверок репозитория, и создаёт отчёт о всех имеющихся проблемах. Этот процесс может занять некоторое время. Наиболее распространенными это предупреждение о «зависших» объектах:

$ git fsck
dangling commit 7281251ddd2a61e38657c827739c57015671a6b3
dangling commit 2706a059f258c6b245f298dc4ff2ccd30ec21a63
dangling commit 13472b7c4b80851a1bc551779171dcb03655e9b5
dangling blob 218761f9d90712d37a9c5e36f406f92202db07eb
dangling commit bf093535a34a4d35731aa2bd90fe6b176302f14f
dangling commit 8e4bec7f2ddaa268bef999853c25755452100f8e
dangling tree d50bb86186bf27b681d25af89d3b5b68382e4085
dangling tree b24c2473f1fd3d91352a624795be026d64c8841f
....


Зависание объектов не проблема. В худшем случае они бесполезно занимают место на диске. Они иногда могут стать последним средством в восстановлении потерянных наработок – см. Раздел “Dangling objects” для более детальной информации.


Изучение зависших объектов

Предположим, вы удалили ветвь, в истории которой содержался необходимый вам релиз. Reflog также был удалён, однако, если вы еще не очищали от мусора репозиторий, то вы по-прежнему ещё можете найти потерянный вами коммит в зависших объектах, о которых вам сообщает команда git-fsck.


См. раздел “Dangling objects” для изучения деталей.


$ git fsck
dangling commit 7281251ddd2a61e38657c827739c57015671a6b3
dangling commit 2706a059f258c6b245f298dc4ff2ccd30ec21a63
dangling commit 13472b7c4b80851a1bc551779171dcb03655e9b5
...


Вы можете изучить любой из этих зависших коммитов, например дав команду:


$ gitk 7281251ddd --not --all


которая делает буквально то, что в ней задано: это означает, что вы хотите увидеть историю описанного зависшего коммита, исключая из неё историю существующих ныне ветвей и тегов.
Таким образом, вы получаете историю от какого-то существующего коммита до потеренного. (И заметим, что эта история может содержать не один коммит: мы ведь получали информацию только о «конце линии» которая зависла, но перед ней может находиться долгоя и сложная история коммита, которая также была отброшена).


Если вы решили, что хотите вернуться эту историю, вы всегда можете создать новую ссылочную, точку указывающию на потерянный коммит, например, востановив эту ветвь как новую :


$ git branch recovered-branch 7281251ddd


Другие виды зависших объектов (blobs и trees), так-же могут существовать, и эти зависшие объекты могут возникать в разных ситуациях.


Так же в этом разделе:
 
MyTetra Share v.0.52
Яндекс индекс цитирования