10.7 Git зсередини - Супроводження та відновлення даних

Інколи, Git автоматично виконує команду під назвою “auto gc”. Переважно, ця команда не робить нічого. Втім, якщо вільних обʼєктів (обʼєктів не у файлі пакунку) забагато, чи забагато пакунків, то Git запускає git gc у повну силу. “gc” — це скорочення для збирання сміття (garbage collect), і ця команда робить різноманітні речі: збирає всі вільні обʼєкти та переносить їх до пакунків, обʼєднує пакунки до одного великого пакунку та вилучає обʼєкти, які стали недосяжними з будь-якого коміту й старші за декілька місяців

Ви можете виконати gc вручну таким чином:

Знову, це зазвичай нічого не зробить. У вас має бути близько 7000 вільних обʼєктів або більш ніж 50 пакунків, щоб Git запустив справжню команду gc. Ви можете змінити ці обмеження за допомогою налаштувань gc.auto та gc.autopacklimit відповідно.

Також gc спакує ваші посилання до одного файлу. Припустімо, що ваше сховище містить наступні гілки та теґи:

Якщо ви виконаєте git gc, то ці файли зникнуть з директорії refs. Git перемістить їх заради ефективності до файлу під назвою .git/packed-refs, який виглядає так:

Якщо ви оновите посилання, Git не буде редагувати цей файл, а натомість запише новий файл до refs/heads. Щоб отримати відповідний SHA-1 для даного посилання, Git шукає це посилання в директорії refs, а потім перевіряє файл packed-refs як запасний варіант. Втім, якщо ви не можете знайти посилання в директорії refs, то напевно воно у файлі packed-refs.

Зверніть увагу на останній рядок цього файлу, що починається з ^. Це означає, що теґ безпосередньо вище є анотованим, і цей рядок — коміт, на який указує цей теґ.

У якийсь момент свого життя з Git, ви можете випадково втратити коміт. Зазвичай, це трапляється через примусове видалення гілки, яка мала якусь працю, а потім виявляється, що гілка зрештою була потрібною; або ви примусово скинули (hard reset) гілку: таким чином загубили коміти, від яких вам щось було потрібно. Припускаючи що це трапилось, як ви можете повернути свої коміти?

Ось приклад, в якому гілку master вашого тестового сховища примусово скинуто до старішого коміту, а потім відновлено втрачені коміти. Спочатку, перегляньмо, в якому стані ви залишили репозиторій:

Тепер, перемістіть гілку master назад до середнього коміту:

У результаті ви втратили два останніх коміти – у вас немає жодної гілки, з якої ці коміти досяжні. Вам потрібно визначити SHA-1 останнього коміту, а потім додати гілку, яка на нього вказує. Найскладніше — знайти SHA-1 останнього коміту – адже навряд чи ви його запамʼятали, чи не так?

Часто, найшвидшим способом є використання інструменту під назвою git reflog. Під час вашої роботи Git тихенько записує де побував ваш HEAD, коли ви його змінюєте. Щоразу ви створюєте коміт або переключаєте гілки, журнал посилань (reflog) оновлюється. Журнал посилань також оновлюється командою git update-ref, що є ще однією причиною використовувати її замість простого запису значення SHA-1 до файлів посилань, що ми розглянули в Посилання Git. Ви можете бачити, де ви були востаннє, якщо виконаєте git reflog:

Тут ви можете бачити два коміти, на які ми були переключались, проте тут про них надано небагато інформації. Щоб побачити цю ж інформацію в кориснішому вигляді, ми можемо виконати git log -g, що надасть вам звичайний вивід журналу для вашого журналу посилань.

Виглядає ніби останній коміт і є втраченим, отже ви можете відновити його, якщо створите нову гілку для нього. Наприклад, ви можете розпочати гілку під назвою recover-branch для цього коміту (ab1afef):

Файно – тепер у вас є гілка під назвою recover-branch, яка знаходиться там, де була гілка master, що робить перші два коміти знову досяжними. Далі, припустімо, що ваша втрата невідомо чому не була записана у журналі посилань – ви можете імітувати це, якщо вилучите recover-branch та журнал посилань. Тепер перші два коміти недосяжні будь-яким способом:

Через те, що дані журналу посилань зберігаються в директорії .git/logs, у вас фактично немає журналу посилань. Як можна тепер відновити коміт? Один засіб для цього — команда git fsck, яка перевіряє цілісність вашої бази даних. Якщо виконати її з опцією --full, то вона покаже вам всі обʼєкти, на які не вказує жоден інший обʼєкт:

У даному випадку, ви можете побачити втрачений коміт після рядка “dangling commit” (висячий коміт). Ви можете відновити його так само: додайте гілку, яка вказує на цей SHA-1.

Існує безліч чудових властивостей Git, проте одна з них може викликати проблеми — той факт, що команда git clone завантажує повну історію проекту, включно з кожною версією кожного файлу. Це нормально, якщо в ньому міститься вихідний код, оскільки Git дуже оптимізовано для ефективного стискання цих даних. Втім, якщо хтось колись в історії вашого проекту додав один величезний файл, кожне клонування завжди буде змушено завантажувати цей файл, навіть якщо його було вилучено з проекту наступного ж коміту. Через те, що він є досяжним в історії, він завжди буде там.

Це може бути величезною проблемою, якщо ви конвертуєте сховища Subversion або Perforce на Git. Через те, що ви не завантажуєте всю історію в цих системах, цей тип додавання призводить до декількох наслідків. Якщо ви імпортували з іншої системи, або іншим чином виявили, що ваше сховище набагато більше, ніж має бути, ось як ви можете знайти та вилучити великі обʼєкти.

Попереджаємо: цей метод знищує історію ваших комітів. Він переписує кожен обʼєкт комітів, починаючи з першого дерева, яке редагує для вилучення посилання на великий файл. Якщо ви робите це відразу після імпортування, перед тим, як хтось розпочав працювати над комітами, то все добре – інакше, ви маєте повідомити всіх співпрацівників, що вони мають перебазувати свою роботу на ваших нових комітах.

Задля демонстації, ви додасте великий файл до вашого тестового сховища, вилучите його в наступному коміті, знайдете його, та назавжди вилучите з репозиторія. Спершу, додайте великий файл до вашої історії:

Йой – ви не хотіли додавати величезний архів до вашого проекту. Краще позбутися його:

Тепер, зробіть gc над вашою базою даних, та подивіться, скільки місця ви використовуєте:

Ви можете виконати команду count-objects, щоб швидко побачити, скільки місця ви використовуєте:

Елемент size-pack зазначає розмір ваших пакунків у кілобайтах, отже ви використовуєте майже 5 мегабайтів. Перед останнім комітом, ви використовували приблизно 2К – зрозуміло, що вилучення файлу в попередньому коміті не вилучило його з вашої історії. Щоразу, коли хтось клонує це сховище, йому доведеться клонувати всі 5Мб лише для того, щоб отримати цей крихітний проект, лише через те, що ви випадково додали великий файл. Позбудьмося його.

Спочатку його треба знайти. У цьому випадку, ви вже знаєте, що це за файл. Проте припустімо, що не знаєте; як вам визначити, який файл чи файли марнують стільки місця? Якщо виконати git gc, то всі обʼєкти потрапляють до пакунку; ви можете визначити великі обʼєкти за допомогою іншої кухонної команди під назвою git verify-pack, якщо упорядкуєте третє поле виводу, яке містить розмір файлу. Ви можете також пропустити результат через команду tail, адже вас цікавлять лише декілька найбільших файлів:

Великий обʼєкт наприкінці: 5Мб. Щоб визначити, що це за файл, ви використаєте команду rev-list, яку ви трохи використовували в Відповідність повідомлення коміту певному формату. Якщо передати --objects до rev-list, то вона надасть список SHA-1 сум всіх комітів, а також блобів з іменами файлів, які з ними асоційовані. Ви можете використати це, щоб знайти імʼя вашого блобу:

Тепер, вам треба вилучити цей файл з усіх дерев з вашого минулого. Ви легко можете бачити, які коміти змінювали цей файл:

Ви маєте переписати всі коміти, починаючи з 7b30847, щоб повністю вилучити цей файл з вашої історії Git. Щоб це зробити, скористайтесь filter-branch, який ви використовували в Переписування історії:

Опція --index-filter схожа на використану в Переписування історії опцію --tree-filter, тільки замість передавання команди, яка змінює файли на диску, ви натомість змінюєте щоразу свій індекс.

Замість вилучення окремого файлу за допомогою чогось на кшталт rm file, ви маєте вилучити його командою git rm --cached – ви мусите видалити його з індексу, не з диску. Варто зробити саме так через швидкість – адже тоді Git не має отримувати кожну ревізію на диск перед виконанням вашого фільтру, і процес може бути набагато, набагато швидшим. Ви можете досягнути того ж самого за допомогою --tree-filter, якщо бажаєте. Опція --ignore-unmatch команди git rm каже їй не вважати помилкою, якщо того, що ви вилучаєте не існує. Нарешті, ви просите filter-branch переписати вашу історію лише починаючи з коміту 7b30847, оскільки ви знаєте, де зʼявилася ця проблема. Інакше, він почне з початку історії, що вимагає невиправдано більше часу.

Ваша історія більше не містить посилання на цей файл. Втім, ваш журнал посилань та декілька посилань, які Git додав, коли ви виконали filter-branch під .git/refs/original досі вказують, отже ви маєте вилучити їх, а потім перепакувати базу даних. Вам треба позбутися будь-чого, що має вказівник на ті старі коміти перед перепакуванням:

Подивімося, скільки місця ви заощадили.

Спаковане сховище зменшило розмір до 8К, що набагато краще, ніж 5Мб. Ви можете зрозуміти за значенням size, що ваш великий файл досі існує у вільних обʼєктах, отже він не зник; проте його не буде переправлено при надсиланні змін чи наступних клонуваннях, а лише це має значення. Якщо ви дійсно бажаєте, то можете вилучити файл цілковито, якщо виконаєте git prune з опцією --expire: