uk/secrets.txt

   1 == Розкриваємо таємниці ==
   2
   3 Ми заглянемо під капот і пояснимо, як Git творить свої чудеса. Я опущу зайві деталі. За більш детальними описами зверніться до http://schacon.github.com/git/user-manual.html[посібник користувача].
   4
   5 === Невидимість ===
   6
   7 Як Git може бути таким ненав'язливим? За винятком періодичних коммітов і злиттів, ви можете працювати так, як ніби й не підозрюєте про якесь управління версіями. Так відбувається до того моменту, коли Git вам знадобиться, і тоді ви з радістю побачите, що він спостерігав за вами весь цей час.
   8
   9 Інші системи управління версіями змушують вас постійно боротися з загородками і бюрократією. Файли можуть бути доступні тільки для читання, поки ви явно не вкажете центральному серверу, які файли ви маєте намір редагувати. Із збільшенням кількості користувачів більшість базових команд починають виконуватися все повільніше. Неполадки з мережею або з центральним сервером повністю зупиняють роботу.
  10
  11 На противагу цьому, Git просто зберігає історію проекту в підкаталозі.git вашого робочого каталогу. Це ваша особиста копія історії, тому ви можете залишатися поза мережею, поки не захочете взаємодіяти з іншими. У вас є повний контроль над долею ваших файлів, оскільки Git в будь-який час може легко відновити збережений стан з.git.
  12
  13 === Цілісність ===
  14
  15 Більшість людей асоціюють криптографію з утриманням інформації в таємниці, але іншим настільки ж важливим завданням є утримання її в цілості. Правильне використання криптографічних хеш-функцій може запобігти випадковому або зловмисному пошкодженню даних.
  16
  17 SHA1 хеш можна розглядати як унікальний 160-бітний ідентифікатор для кожного рядка байт, з яким ви стикаєтеся у вашому житті. Навіть більше того: для кожного рядка байтів, який будь-яка людина коли-небудь буде використовувати протягом багатьох життів.
  18
  19 Оскільки SHA1 хеш сам є послідовністю байтів, ми можемо отримати хеш рядка байтів, що містить інші хеши. Це просте спостереження на подив корисно: шукайте 'hash chains' (ланцюги хешів). Пізніше ми побачимо, як Git використовує їх для ефективного забезпечення цілісності даних.
  20
  21 Кажучи коротко, Git зберігає ваші дані в підкаталозі `.git/objects`, де замість нормальних імен файлів ви знайдете тільки ідентифікатори. Завдяки використанню ідентифікаторів в якості імен файлів, а також деяких хитрощів з файлами блокувань і тимчасовими мітками, Git перетворює будь-яку скромну файлову систему в ефективну і надійну базу даних.
  22
  23 === Інтелект ===
  24
  25 Як Git дізнається, що ви перейменували файл, навіть якщо ви ніколи не згадували про це явно? Звичайно, ви можете запустити *git mv*; але це те ж саме, що *git rm*, а потім *git add*.
  26
  27 Git евристично знаходить файли, які були перейменовані або скопійовані між сусідніми версіями. Насправді він може виявити, що ділянки коду були переміщені або скопійовані між файлами! Хоча Git не може охопити всі випадки, він все ж робить гідну роботу, і ця функція постійно покращується. Якщо вона не спрацювала, спробуйте опції, що включають більш ресурсномістке виявлення копіювання і подумайте про оновлення.
  28
  29 === Індексація ===
  30
  31 Для кожного відстежуваного файлу, Git записує таку інформацію, як розмір, час створення і час останньої зміни, у файлі, відомому як 'index'. Щоб визначити, чи був файл змінений, Git порівнює його поточні характеристики із збереженими в індексі. Якщо вони збігаються, то Git не стане перечитувати файл заново.
  32
  33 Оскільки зчитування цієї інформації значно швидше, ніж читання всього файлу, то якщо ви редагували лише кілька файлів, Git може оновити свій індекс майже миттєво.
  34
  35 Ми відзначали раніше, що індекс – це буферна зона. Чому набір властивостей файлів виступає таким буфером? Тому що команда add поміщає файли в базу даних Git і у відповідності з цим оновлює ці властивості; тоді як команда commit без опцій створює комміт, заснований тільки на цих властивостях і файлах, які вже в базі даних.
  36
  37 === Походження Git ===
  38
  39 Це http://lkml.org/lkml/2005/4/6/121[повідомлення в поштовій розсилці ядра Linux] описує послідовність подій, які призвели до появи Git. Весь цей тред – приваблива археологічна розкопка для істориків Git.
  40
  41 === База даних об'єктів ===
  42
  43 Кожна версія ваших даних зберігається в «базі даних об’єктів», що живе в підкаталозі `.git/objects`. Інші „жителі“ `.git/` містять вторинні дані: індекс, імена гілок, теги, параметри налаштування, журнали, нинішнє розташування „головного“ комміта і так далі. База об’єктів проста і елегантна, і в ній джерело сили Git.
  44
  45 Кожен файл всередині `.git/objects` — це „об’єкт“. Нас цікавлять три типи об’єктів: об’єкти „блоб“, об’єкти „дерева“ і об’єкти „комміти“.
  46
  47 === Блоби ===
  48
  49 Для початку один фокус. Виберіть ім'я файлу – будь-яке ім'я файлу. У порожньому каталозі:
  50
  51  $ echo sweet > ВАШЕ_ІМ’Я_ФАЙЛУ
  52  $ git init
  53  $ git add .
  54  $ find .git/objects -type f
  55
  56 Ви побачите +.git/objects/aa/823728ea7d592acc69b36875a482cdf3fd5c8d+.
  57
  58 Звідки я знаю це, не знаючи імені файлу? Це тому, що SHA1 хеш рядка
  59
  60  "blob" SP "6" NUL "sweet" LF
  61
  62 дорівнює aa823728ea7d592acc69b36875a482cdf3fd5c8d,
  63 де SP – це пробіл, NUL — нульовий байт і LF — переведення строки. Ви можете перевірити це, набравши
  64
  65   $ printf "blob 6\000sweet\n" | sha1sum
  66
  67 Git використовує „адресацію по вмісту“: файли зберігаються у відповідності не з іменами, а з хешамі вмісту, — у файлі, який ми називаємо „блоб-об’єктом“. Хеш можна розуміти як унікальний ідентифікатор вмісту файлу, що означає звернення до файлів за їх вмістом. Початковий `blob 6` — лише заголовок, що складається з типу об'єкта і його довжини в байтах і спрощує внутрішній облік.
  68
  69 Таким чином, я можу легко передбачити, що ви побачите. Ім'я файлу не має значення: для створення блоб-об’єкта використовується тільки його вміст.
  70
  71 Вам може бути цікаво, що відбувається з однаковими файлами. Спробуйте додати копії свого файлу з якими завгодно іменами. Зміст +.git/objects+ залишиться тим же незалежно від того, скільки копій ви додасте. Git зберігає дані лише одного разу.
  72
  73 Доречі, файли в каталозі +.git/objects+ стискаються за допомогою zlib тому ви не зможете переглянути їх безпосередньо. Пропустіть їх через фільтр http://www.zlib.net/zpipe.c[zpipe -d], або наберіть
  74
  75  $ git cat-file -p aa823728ea7d592acc69b36875a482cdf3fd5c8d
  76
  77 що виведе зазначений об’єкт у вигляді, придатному для читання.
  78
  79 === Дерева ===
  80
  81 Але де ж імена файлів? Вони повинні зберігатися на якомусь рівні. Git звертається за іменами під час комміта:
  82
  83  $ git commit  # Введіть який-небудь опис
  84  $ find .git/objects -type f
  85
  86 Тепер ви повинні побачити три об'єкти. На цей раз я не можу сказати вам, що з себе представляють два нових файли, оскільки це частково залежить від обраного вами імені файлу. Далі будемо припускати, що ви назвали його ``rose''. Якщо це не так, то ви можете переписати історію, щоб вона виглядала як ніби ви це зробили:
  87
  88  $ git filter-branch --tree-filter 'mv ВАШЕ_ІМ’Я_ФАЙЛУ rose'
  89  $ find .git/objects -type f
  90
  91 Тепер ви повинні побачити файл
  92 +.git/objects/05/b217bb859794d08bb9e4f7f04cbda4b207fbe9+, оскільки це
  93 SHA1 хеш його вмісту:
  94
  95  «tree» SP «32» NUL «100644 rose» NUL 0xaa823728ea7d592acc69b36875a482cdf3fd5c8d
  96
  97 Перевірте, що цей файл дійсно містить зазначений рядок, набравши
  98
  99  $ echo 05b217bb859794d08bb9e4f7f04cbda4b207fbe9 | git cat-file --batch
 100
 101 З zpipe легко перевірити хеш:
 102
 103  $ zpipe -d < .git/objects/05/b217bb859794d08bb9e4f7f04cbda4b207fbe9 | sha1sum
 104
 105 Перевірка хешу за допомогою cat-file складніша, оскільки її висновок містить не тільки „сирий“ розпакований файл об’єкта.
 106
 107 Цей файл — об'єкт „дерево“ ('tree', прим. пер.): перелік ланцюгів, що складаються з типу, імені файлу та його хешу. У нашому прикладі: тип файлу — 100644, що означає, що `rose` це звичайний файл; а хеш — блоб-об’єкт, в якому міститься вміст `rose`. Інші можливі типи файлів: виконувані файли, символічні посилання або каталоги. В останньому випадку, хеш вказує на об’єкт „дерево“.
 108
 109 Якщо ви запускали filter-branch, у вас є старі об’єкти які вам більше не потрібні. Хоча після закінчення терміну зберігання вони будуть викинуті автоматично, ми видалимо їх зараз, щоб було легше стежити за нашим іграшковим прикладом:
 110
 111  $ rm -r .git/refs/original
 112  $ git reflog expire --expire=now --all
 113  $ git prune
 114
 115 Для реальних проектів зазвичай краще уникати таких команд, оскільки ви знищуєте резервні копії. Якщо ви хочете мати чисте сховище, то звичайно краще зробити свіжий клон. Крім того, будьте обережні при безпосередньому втручанні в каталог +.git+: що якщо інша команда Git працює в цей же час, або раптово збій в електропостачанні? Взагалі кажучи, посилання потрібно видаляти за допомогою *git update-ref -d*, хоча зазвичай ручне видалення +refs/original+ безпечне.
 116
 117 === Комміти ===
 118
 119 Ми розглянули два з трьох об'єктів. Третій об’єкт — „комміт“ (commit). Його вміст залежить від опису комміта, як і від дати і часу його створення. Для відповідповідності тому, що ми маємо, ми повинні трохи „підкрутити“ Git:
 120
 121  $ git commit --amend -m Shakespeare  # Змінимо опис комміта.
 122  $ git filter-branch --env-filter 'export
 123      GIT_AUTHOR_DATE="Fri 13 Feb 2009 15:31:30 -0800"
 124      GIT_AUTHOR_NAME="Alice"
 125      GIT_AUTHOR_EMAIL="alice@example.com"
 126      GIT_COMMITTER_DATE="Fri, 13 Feb 2009 15:31:30 -0800"
 127      GIT_COMMITTER_NAME="Bob"
 128      GIT_COMMITTER_EMAIL="bob@example.com"'  # Підробимо тимчасові мітки і авторів.
 129  $ find .git/objects -type f
 130
 131 Тепер ви повинні побачити
 132 +.git/objects/49/993fe130c4b3bf24857a15d7969c396b7bc187+
 133 який є SHA1 хешем його вмісту:
 134
 135  «commit 158» NUL
 136  «tree 05b217bb859794d08bb9e4f7f04cbda4b207fbe9» LF
 137  «author Alice <alice@example.com> 1234567890 -0800» LF
 138  «committer Bob <bob@example.com> 1234567890 -0800» LF
 139  LF
 140  «Shakespeare» LF
 141
 142 Як і раніше, ви самі можете запустити zpipe або cat-file, щоб побачити це.
 143
 144 Це перший комміт, тому тут немає батьківських коммітів, але подальші комміти завжди будуть містити хоча б один рядок, що ідентифікує батьківський комміт.
 145
 146 === Невідрізнено від чаклунства ===
 147
 148 Секрети Git виглядають занадто простими. Схоже, що ви могли б об’єднати кілька shell-скриптів і додати трохи коду на C, щоб зробити все це в лічені години: суміш базових операцій з файлами і SHA1-хешування, приправлена блокувальними файлами і fsync для надійності. По суті, це точний опис ранніх версій Git. Тим не менше, крім геніальних трюків з упаковкою для економії місця і з індексацією для економії часу, ми тепер знаємо, як спритно Git перетворює файлову систему в базу даних, що ідеально підходить для керування версіями.
 149
 150 Наприклад, якщо який-небудь файл у базі даних об’єктів пошкоджений через помилку диска, то його хеш тепер не співпаде, що приверне нашу увагу до проблеми. За допомогою хешування хешів інших об’єктів, ми підтримуємо цілісність на всіх рівнях. Комміти атомарні, так що в них ніколи не можна записати лише частину змін: ми можемо обчислити хеш комміта і зберегти його в базу даних тільки зберігши всі відповідні дерева, блоби і батьківські комміти. База даних об’єктів нечутлива до непередбачених переривань роботи, таких як перебої з живленням.
 151
 152 Ми завдаємо поразки навіть найбільш хитрим супротивникам. Припустимо, хтось намагається таємно змінити вміст файлу в давньої версії проекту. Щоб база об’єктів виглядала неушкодженою, він також повинен змінити хеш відповідного блоб-об'єкта, оскільки це тепер інша послідовність байтів. Це означає, що потрібно поміняти хеши всіх об’єктів дерев, що посилаються на цей файл; що в свою чергу змінить хеши всіх об’єктів коммітів за участю таких дерев; а також і хеши всіх нащадків цих коммітів. Внаслідок цього хеш офіційної головної ревізії буде відрізнятися від аналогічного хешу в цьому зіпсованому сховищі. По ланцюжку незбіжних хешів ми можемо точно обчислити спотворений файл, як і комміт, де він спочатку був пошкоджений.
 153
 154 Одним словом, неможливо підробити сховище Git, залишивши непошкодженими двадцять байт, що відповідають останньому комміту.
 155
 156 Як щодо відомих характерних особливостей Git? Галуження? Злиття? Теги? Очевидні подробиці. Поточна «голова» зберігається у файлі +.git/HEAD+, що містить хеш об’єкта комміта.
 157 Хеш оновлюється під час комміта, а також при виконанні багатьох інших команд. З гілками все аналогічно: це файли в +.git/refs/heads+. Те ж і з тегами: вони живуть у +.git/refs/tags+, але їх оновлює інший набір команд.