-
1. Вступ
- 1.1 Про систему контролю версій
- 1.2 Коротка історія Git
- 1.3 Основи Git
- 1.4 Git, зазвичай, тільки додає дані
- 1.5 Три стани
- 1.6 Командний рядок
- 1.7 Інсталяція Git
- 1.8 Початкове налаштування Git
- 1.9 Отримання допомоги
- 1.10 Підсумок
-
2. Основи Git
- 2.1 Створення Git-сховища
- 2.2 Запис змін до репозиторія
- 2.3 Перегляд історії комітів
- 2.4 Скасування речей
- 2.5 Взаємодія з віддаленими сховищами
- 2.6 Теґування
- 2.7 Псевдоніми Git
- 2.8 Підсумок
-
3. Галуження в git
- 3.1 Гілки у кількох словах
- 3.2 Основи галуження та зливання
- 3.3 Управління гілками
- 3.4 Процеси роботи з гілками
- 3.5 Віддалені гілки
- 3.6 Перебазовування
- 3.7 Підсумок
-
4. Git на сервері
- 4.1 Протоколи
- 4.2 Отримання Git на сервері
- 4.3 Генерація вашого публічного ключа SSH
- 4.4 Налаштування Серверу
- 4.5 Демон Git
- 4.6 Розумний HTTP
- 4.7 GitWeb
- 4.8 GitLab
- 4.9 Варіанти стороннього хостингу
- 4.10 Підсумок
-
5. Розподілений Git
-
6. GitHub
-
7. Інструменти Git
- 7.1 Вибір ревізій
- 7.2 Інтерактивне індексування
- 7.3 Ховання та чищення
- 7.4 Підписання праці
- 7.5 Пошук
- 7.6 Переписування історії
- 7.7 Усвідомлення скидання (reset)
- 7.8 Складне злиття
- 7.9 Rerere
- 7.10 Зневадження з Git
- 7.11 Підмодулі
- 7.12 Пакування
- 7.13 Заміна
- 7.14 Збереження посвідчення (credential)
- 7.15 Підсумок
-
8. Налаштування Git
-
9. Git and Other Systems
- 9.1 Git як клієнт
- 9.2 Міграція на Git
- 9.3 Підсумок
-
10. Git зсередини
- 10.1 Кухонні та парадні команди
- 10.2 Об’єкти Git
- 10.3 Посилання Git
- 10.4 Файли пакунки
- 10.5 Специфікація посилань (refspec)
- 10.6 Протоколи передачі
- 10.7 Супроводження та відновлення даних
- 10.8 Змінні середовища
- 10.9 Підсумок
-
A1. Додаток A: Git в інших середовищах
- A1.1 Графічні інтерфейси
- A1.2 Git у Visual Studio
- A1.3 Git в Eclipse
- A1.4 Git у Bash
- A1.5 Git у Zsh
- A1.6 Git у Powershell
- A1.7 Підсумок
-
A2. Додаток B: Вбудовування Git у ваші застосунки
- A2.1 Git з командного рядка
- A2.2 Libgit2
- A2.3 JGit
- A2.4 go-git
-
A3. Додаток C: Команди Git
- A3.1 Налаштування та конфігурація
- A3.2 Отримання та створення проектів
- A3.3 Базове збереження відбитків
- A3.4 Галуження та зливання
- A3.5 Поширення й оновлення проектів
- A3.6 Огляд та порівняння
- A3.7 Зневаджування
- A3.8 Латання (patching)
- A3.9 Електронна пошта
- A3.10 Зовнішні системи
- A3.11 Адміністрування
- A3.12 Кухонні команди
10.2 Git зсередини - Об’єкти Git
Об’єкти Git
Git є файловою системою адресованого вмісту. Чудово. Що це означає? Це означає, що в підвалинах Git — це просте сховище даних для ключів-значень. А це означає, що ви можете вставити будь-який вміст до сховища Git, а Git поверне вам унікальний ключ, який ви можете потім використати для отримання цього вмісту.
Кухонна команда git hash-object
приймає дані, зберігає їх у вашій директорії .git/objects
(база даних обʼєктів), та повертає вам унікальний ключ, що тепер вказує на цей обʼєкт.
Спочатку, ви створюєте нове сховище Git та перевіряєте, що директорія objects
(очікувано) порожня:
$ git init test
Initialized empty Git repository in /tmp/test/.git/
$ cd test
$ find .git/objects
.git/objects
.git/objects/info
.git/objects/pack
$ find .git/objects -type f
Git створив директорію objects
та піддиректорії pack
та info
в ній, проте звичайних файлів там немає.
Тепер використаймо git hash-object
, щоб створити новий обʼєкт даних та вручну зберегти їх у вашій новій базі даних Git:
$ echo 'test content' | git hash-object -w --stdin
d670460b4b4aece5915caf5c68d12f560a9fe3e4
У найпростішому варіанті git hash-object
приймає вміст та просто повертає унікальний ключ, що використовувався би для збереження цих даних у базі даних Git.
Опція -w
інструктує команду не лише просто повернути ключ, а й зберегти його до бази даних.
Нарешті, опція --stdin
каже git hash-object
отримати вміст з stdin; інакше команда очікує отримати шлях до файлу в аргументах.
Вивід від команди — 40 символьна хеш-сума. Це SHA-1 хеш — перевірочна сума вмісту, який ви зберігаєте плюс заголовок (header), про який ви дізнаєтесь трошки пізніше. Тепер ви можете побачити, як Git зберігає ваші дані:
$ find .git/objects -type f
.git/objects/d6/70460b4b4aece5915caf5c68d12f560a9fe3e4
Якщо ви знову перевірите, що містить ваша директорія objects
, то побачите новий файл.
Ось так Git зберігає вміст спочатку — як один файл для кожного шматочку вмісту, названий SHA-1 сумою вмісту та заголовком.
Піддиректорія названа першими двома символами SHA-1, а файл рештою 38 символами.
Щойно вміст зберігається у вашій базі даних, ви можете переглянути його за допомогою команди git cat-file
.
Ця команда є чимось на кшталт швейцарського ножа для перегляду об’єктів Git.
Якщо передати -p
, то команда cat-file
спочатку розбереться, якого формату вміст, та відобразить його відповідно:
$ git cat-file -p d670460b4b4aece5915caf5c68d12f560a9fe3e4
test content
Тепер, ви можете додавати вміст до Git та отримувати його назад. Ви також можете робити це з вмістом файлів. Наприклад, ви можете зробити просте керування версіями файлу. Спочатку, створіть новий файл та збережіть його вміст у базі даних:
$ echo 'version 1' > test.txt
$ git hash-object -w test.txt
83baae61804e65cc73a7201a7252750c76066a30
Потім, запишіть новий вміст до файлу та збережіть його знову:
$ echo 'version 2' > test.txt
$ git hash-object -w test.txt
1f7a7a472abf3dd9643fd615f6da379c4acb3e3a
Ваша база даних обʼєктів тепер містить обидві версії цього нового файлу (а також перший вміст, який ви там зберегли):
$ find .git/objects -type f
.git/objects/1f/7a7a472abf3dd9643fd615f6da379c4acb3e3a
.git/objects/83/baae61804e65cc73a7201a7252750c76066a30
.git/objects/d6/70460b4b4aece5915caf5c68d12f560a9fe3e4
Зараз ви можете видалити локальну копію файлу test.txt
і використати Git, щоб отримати з бази даних обʼєктів або першу збережену версію:
$ git cat-file -p 83baae61804e65cc73a7201a7252750c76066a30 > test.txt
$ cat test.txt
version 1
або другу:
$ git cat-file -p 1f7a7a472abf3dd9643fd615f6da379c4acb3e3a > test.txt
$ cat test.txt
version 2
Проте запам’ятовувати SHA-1 ключ для кожної версії вашого файлу непрактично; на додаток, ви не зберігаєте ім’я файлу у вашій системі — лише вміст.
Цей тип об’єкта називається блоб.
Git може вам видати тип будь-якого об’єкта, якщо надати його SHA-1 ключ команді git cat-file -t
:
$ git cat-file -t 1f7a7a472abf3dd9643fd615f6da379c4acb3e3a
blob
Об’єкти дерева
Далі ми розглянемо тип об’єкта Git дерево, який вирішує проблему збереження імені файлу, а також дозволяє зберігати групу файлів разом. Git зберігає вміст у схожий на файлову систему UNIX спосіб, проте дещо спрощений. Весь вміст зберігається як об’єкти дерева та блоби, дерева відповідають UNIX директоріям, а блоб схожий на inode чи вміст файлу. Один об’єкт дерево містить один чи більше елементів дерева, кожен з яких містить SHA-1 вказівник на блоб або піддерево з асоційованими правами доступу, типом та іменем файлу. Наприклад, найновіше дерево в проекті може виглядати так:
$ git cat-file -p master^{tree}
100644 blob a906cb2a4a904a152e80877d4088654daad0c859 README
100644 blob 8f94139338f9404f26296befa88755fc2598c289 Rakefile
040000 tree 99f1a6d12cb4b6f19c8655fca46c3ecf317074e0 lib
Синтаксис master^{tree}
визначає об’єкт дерево, на яке вказує останній коміт вашої гілки master
.
Зверніть увагу, що піддиректорія lib
— це не блоб, а вказівник на інше дерево:
$ git cat-file -p 99f1a6d12cb4b6f19c8655fca46c3ecf317074e0
100644 blob 47c6340d6459e05787f644c2447d2595f5d3a54b simplegit.rb
Концептуально, дані, які зберігає Git, скидаються на щось таке:
Ви можете доволі легко створити власне дерево.
Git, зазвичай, створює дерево, коли бере стан вашого індексу чи області додавання (staging area) та записує низку об’єктів дерев з нього.
Отже, щоб створити об’єкт дерево, спочатку треба налаштувати індекс, додавши до нього деякі файли.
Щоб створити індекс з єдиним елементом — першою версією вашого файлу test.txt
— ви можете скористатись кухонною командою git update-index
.
Ви використовуєте цю команду, щоб штучно додати більш ранню версію файлу test.txt
до нового індексу.
Ви маєте передати опцію --add
, оскільки файл ще не існує в нашому індексі (у вас навіть немає індексу поки що) та --cacheinfo
, оскільки файлу, який ви додаєте, не існує у вашій директорії, проте існує у вашій базі даних.
Потім, ви визначаєте права доступу, SHA-1 та ім’я файлу:
$ git update-index --add --cacheinfo 100644 \
83baae61804e65cc73a7201a7252750c76066a30 test.txt
У даному випадку, ви встановили права доступу 100644
, що означає звичайний файл.
Інші можливі значення — 100755
, що означає виконанний файл; та 120000
, що означає символічне посилання.
Права доступу походять від звичайних прав доступу UNIX, проте вони набагато менш гнучкі — ці три варіанти єдині, які можна задати для файлів (блобів) у Git (хоча інші використовуються для директорія та підмодулів).
Тепер, ви можете використати git write-tree
, щоб записати індекс до об’єкта дерева.
Опція -w
не потрібна — виклик цієї команди автоматично створює об’єкт дерева з індексу, якщо цього дерева ще не існує:
$ git write-tree
d8329fc1cc938780ffdd9f94e0d364e0ea74f579
$ git cat-file -p d8329fc1cc938780ffdd9f94e0d364e0ea74f579
100644 blob 83baae61804e65cc73a7201a7252750c76066a30 test.txt
Ви також можете переконатись, що цей об’єкт є деревом за допомогою вже знайомої вам команди git cat-file
:
$ git cat-file -t d8329fc1cc938780ffdd9f94e0d364e0ea74f579
tree
Тепер ви створите нове дерево з другою версією test.txt
, а також новий файл:
$ echo 'new file' > new.txt
$ git update-index --add --cacheinfo 100644 \
1f7a7a472abf3dd9643fd615f6da379c4acb3e3a test.txt
$ git update-index --add new.txt
Ваш індекс тепер має нову версію test.txt
, а також новий файл new.txt
.
Збережіть це дерево (запишіть стан індексу до об’єкта дерева) та подивіться, як воно виглядає:
$ git write-tree
0155eb4229851634a0f03eb265b69f5a2d56f341
$ git cat-file -p 0155eb4229851634a0f03eb265b69f5a2d56f341
100644 blob fa49b077972391ad58037050f2a75f74e3671e92 new.txt
100644 blob 1f7a7a472abf3dd9643fd615f6da379c4acb3e3a test.txt
Зауважте, що це дерево містить обидва файли, а також, що SHA-1 файлу test.txt
таке саме, як у вищенаведеній `верcії 2'' цього файлу.
Заради розваги, додайте перше дерево як піддиректорію другого.
Ви можете читати дерева до індексу, якщо викликаєте `git read-tree
.
У даному випадку, ви можете зчитати існуюче дерево до вашого індексу як піддерево за допомогою опції --prefix
цієї команди:
$ git read-tree --prefix=bak d8329fc1cc938780ffdd9f94e0d364e0ea74f579
$ git write-tree
3c4e9cd789d88d8d89c1073707c3585e41b0e614
$ git cat-file -p 3c4e9cd789d88d8d89c1073707c3585e41b0e614
040000 tree d8329fc1cc938780ffdd9f94e0d364e0ea74f579 bak
100644 blob fa49b077972391ad58037050f2a75f74e3671e92 new.txt
100644 blob 1f7a7a472abf3dd9643fd615f6da379c4acb3e3a test.txt
Якщо ви створили робочу директорію з нового дерева, яке ви щойно записали, то отримаєте два файли на верхньому рівні робочої директорії та піддиректорію під назвою bak
, яка містить першу версію файлу test.txt
.
Ви можете вважати, що Git зберігає дані для цих структур наступним чином:
Об’єкти комітів
Якщо ви виконали всі вищенаведені команди, то у вас тепер є три дерева, які відповідають різним відбиткам вашого проекту, за якими ви бажаєте слідкувати, проте залишається попередня проблема: ви маєте пам’ятати всі три значення SHA-1, щоб згадати відбитки. Ви також не маєте будь-якої інформації про те, хто створив відбитки, коли вони були створені, чи чому їх створили. Це базова інформація, яку для вас зберігає об’єкт коміту.
Щоб створити об’єкт коміту, треба викликати commit-tree
та задати єдиний SHA-1 дерева, та які об’єкти комітів, якщо такі існують, йому безпосередньо передували.
Почніть з першого збереженого дерева:
$ echo 'first commit' | git commit-tree d8329f
fdf4fc3344e67ab068f836878b6c4951e3b15f3d
Ви отримаєте інше значення хешу через інший час створення й авторські дані.
Замінюйте хеши комітів і міток на власні суми надалі в цьому розділі.
Тепер ви можете подивитись на свій новий об’єкт коміт за допомогою git cat-file
:
$ git cat-file -p fdf4fc3
tree d8329fc1cc938780ffdd9f94e0d364e0ea74f579
author Scott Chacon <schacon@gmail.com> 1243040974 -0700
committer Scott Chacon <schacon@gmail.com> 1243040974 -0700
first commit
Формат об’єкта коміту простий: він задає дерево верхнього рівня для відбитку проекту на той час; інформацію про автора та того, хто створив коміт (використовує ваші налаштування user.name
та user.email
, а також час створення); порожній рядок, а потім повідомлення коміту.
Далі, ви запишете інші два коміти об’єктів, кожен з яких посилається на той, що був перед ним:
$ echo 'second commit' | git commit-tree 0155eb -p fdf4fc3
cac0cab538b970a37ea1e769cbbde608743bc96d
$ echo 'third commit' | git commit-tree 3c4e9c -p cac0cab
1a410efbd13591db07496601ebc7a059dd55cfe9
Кожен з трьох об’єктів комітів вказує на одне з трьох дерев, які ви створили.
Доволі дивно, проте у вас тепер є справжня історія Git, яку ви можете переглядати командою git log
, якщо виконаєте її з SHA-1 останнього коміту:
$ git log --stat 1a410e
commit 1a410efbd13591db07496601ebc7a059dd55cfe9
Author: Scott Chacon <schacon@gmail.com>
Date: Fri May 22 18:15:24 2009 -0700
third commit
bak/test.txt | 1 +
1 file changed, 1 insertion(+)
commit cac0cab538b970a37ea1e769cbbde608743bc96d
Author: Scott Chacon <schacon@gmail.com>
Date: Fri May 22 18:14:29 2009 -0700
second commit
new.txt | 1 +
test.txt | 2 +-
2 files changed, 2 insertions(+), 1 deletion(-)
commit fdf4fc3344e67ab068f836878b6c4951e3b15f3d
Author: Scott Chacon <schacon@gmail.com>
Date: Fri May 22 18:09:34 2009 -0700
first commit
test.txt | 1 +
1 file changed, 1 insertion(+)
Дивовижно.
Ви щойно використовували низькорівневі операції, щоб створити історію Git без використання бодай однієї клієнтської.
Це, по суті, Git і робить, коли ви виконуєте команди git add
та git commit
— зберігає блоби для файлів, які змінилися, оновлює індекс, записує дерева, та записує об’єкти комітів, які посилаються на дерева верхнього рівня та коміти, які йшли безпосередньо перед ними.
Ці три головні об’єкти Git — блоб, дерево та коміт — спочатку зберігаються як окремі файли у вашій директорії .git/objects
.
Ось всі об’єкти в директорії нашого прикладу, з коментарем про те, що вони зберігають:
$ find .git/objects -type f
.git/objects/01/55eb4229851634a0f03eb265b69f5a2d56f341 # tree 2
.git/objects/1a/410efbd13591db07496601ebc7a059dd55cfe9 # commit 3
.git/objects/1f/7a7a472abf3dd9643fd615f6da379c4acb3e3a # test.txt v2
.git/objects/3c/4e9cd789d88d8d89c1073707c3585e41b0e614 # tree 3
.git/objects/83/baae61804e65cc73a7201a7252750c76066a30 # test.txt v1
.git/objects/ca/c0cab538b970a37ea1e769cbbde608743bc96d # commit 2
.git/objects/d6/70460b4b4aece5915caf5c68d12f560a9fe3e4 # 'test content'
.git/objects/d8/329fc1cc938780ffdd9f94e0d364e0ea74f579 # tree 1
.git/objects/fa/49b077972391ad58037050f2a75f74e3671e92 # new.txt
.git/objects/fd/f4fc3344e67ab068f836878b6c4951e3b15f3d # commit 1
Якщо ви прослідкуєте за всіма внутрішніми вказівниками, то отримаєте граф об’єктів, схожий на цей:
Зберігання обʼєктів
Ми вже згадували, що разом з вмістом кожного обʼєкта бази даних Git зберігається заголовок. Приділімо хвилинку тому, щоб подивитись, як Git зберігає свої обʼєкти. Ви побачите, як зберегти обʼєкт блоб — у цьому випадку, рядок ``what is up, doc?'' — в інтерактивному режимі скриптової мови Ruby.
Ви можете запустити інтерактивний режим Ruby командою irb
:
$ irb
>> content = "what is up, doc?"
=> "what is up, doc?"
Спочатку Git формує заголовок, що починається з типу обʼєкта — у цьому випадку це блоб. Після цієї першої частини заголвку йде пробіл, а потім — розмір вмісту в байтах, та нарешті нульовий байт:
>> header = "blob #{content.length}\0"
=> "blob 16\u0000"
Git з’єднує заголовок з вмістом, а потім обчислює суму SHA-1 цього нового вмісту.
Ви можете обчислити SHA-1 суму рядка в Ruby, якщо підключите бібліотеку SHA1 командою requier
, а потім викличете Digest::SHA1.hexdigest()
для рядка:
>> store = header + content
=> "blob 16\u0000what is up, doc?"
>> require 'digest/sha1'
=> true
>> sha1 = Digest::SHA1.hexdigest(store)
=> "bd9dbf5aae1a3862dd1526723246b20206e5fc37"
Git стискає новий вміст за допомогою zlib, що також може зробити Ruby, використовуючи бібліотеку zlib.
Спершу, треба підключити бібліотеку, а потім виконати Zlib::Deflate.deflate()
з вмістом:
>> require 'zlib'
=> true
>> zlib_content = Zlib::Deflate.deflate(store)
=> "x\x9CK\xCA\xC9OR04c(\xCFH,Q\xC8,V(-\xD0QH\xC9O\xB6\a\x00_\x1C\a\x9D"
Нарешті, ви запишете вміст, що був зменшений за допомогою zlib, до обʼєкту на диску.
Ви визначите шлях до обʼєкту, який ви бажаєте записати (перші два символи значення SHA-1 будуть імʼям піддиректорії, решта 38 символів будуть імʼям файлу в цій піддиректорії).
У Ruby, ви можете використати функцію FileUtils.mkdir_p()
для створення піддиректорії, якщо вона не існує.
Потім, відкрийте файл: File.open()
; та запишіть вже стиснутий zlib вміст до файлу, викликавши write()
з отриманим дескриптором файлу:
>> path = '.git/objects/' + sha1[0,2] + '/' + sha1[2,38]
=> ".git/objects/bd/9dbf5aae1a3862dd1526723246b20206e5fc37"
>> require 'fileutils'
=> true
>> FileUtils.mkdir_p(File.dirname(path))
=> ".git/objects/bd"
>> File.open(path, 'w') { |f| f.write zlib_content }
=> 32
Ось і все — ви створили чинний обʼєкт Git типу блоб. Усі обʼєкти Git зберігаються однаково, лише з різними типами — замість рядка blob, заголовок починатиметься з commit або tree. Також, хоча вміст блобу може бути майже будь-чим, вміст коміту та дерева мають строгий формат.