Git
Chapters ▾ 2nd Edition

10.1 Git зсередини - Кухонні та парадні команди

Можливо, ви перейшли сюди після одного з перших розділів, а може й після послідовного вивчення всієї книжки до цього місця — у будь-якому разі, саме тут ми перейдемо до внутрішніх процесів та реалізації Git. Ми дійшли висновку, що розуміння цієї інформації було принципово важливим для усвідомлення того, наскільки Git є корисним та потужним, та інші сперечалися з нами, кажучи, що це може збивати з пантелику початківців та бути для них надміру складним. Тому ми зробили це обговорення останнім розділом книги, щоб рано чи пізно ви могли прочитати його під час навчального процесу. Лишаємо це на ваш розсуд.

А тепер, розпочнімо. По-перше, якщо це досі не стало зрозумілим, Git — контентно-адресована (асоціативна) файлова система із надбудовою у вигляді користувацького інтерфейсу СКВ. За мить ви дізнаєтеся більше про те, що це одначає.

У час раннього становлення Git (переважно до версії 1.5), користувацький інтерфейс був значно складнішим, бо він більше підкреслював цю файлову систему, аніж зручність СКВ. Протягом останніх кількох років користувацький інтерфейс вдосконалювався і став простим та зрозумілим у використанні; втім, досі зустрічається стереотип щодо раннього інтерфейсу Git, який був складним і тяжким для вивчення.

Шар асоціативної файлової системи неймовірно крутий, тож ми охопимо його першим у цьому розділі; потім ви дізнаєтеся про механізми передачі та завдання з обслуговування репозиторія, з якими вам можете знадобитися коли-небудь мати справу.

Кухонні та парадні команди

Ця книга переважно розповідає про використання Git за допомогою близько трьох десятків підкоманд на кшталт checkout, branch, remote. Та оскільки Git спершу був більше інструментом для системи керування версіями, ніж повною СКВ з дружнім інтерфейсом, існує купа підкоманд, що здійснюють низькорівневу роботу і були створені для послідовного використання у стилі UNIX або використання у скриптах. Ці команди зазвичай називають “кухонними” (англійський термін “plumbing” — трубопровід, сантехніка), а орієнтовані на користувача — “парадними” (англійський термін “porcelain” — порцелянові).

Як ви вже напевно помітили, перші дев’ять розділів книги були присвячені переважно парадним командам. У цьому розділі розглядатимуться саме низькорівневі кухонні команди, які дають доступ до внутрішніх процесів Git, та допомогають продемонструвати як і чому Git працює саме так, а не інакше. Багато з цих команд призначені не для ручного використання з командного рядка, а є блоками для побудови нових інструментів та користувацьких скриптів.

Коли ви виконуєте git init у новій чи існуючій теці, Git створює теку .git, де знаходиться майже все, що Git зберігає і чим оперує. Якщо ви бажаєте зробити резервну копію чи клон свого репозиторія, копіювання лише цієї теки в інше місце дає вам майже все, що необхідно. Поточний розділ присвячений вмісту цієї теки. Зазвичай щойно створена тека .git має такий вигляд:

$ ls -F1
config
description
HEAD
hooks/
info/
objects/
refs/

Залежно від версії Git, там може бути ще щось, та вищенаведений приклад є свіжим репозиторієм — це те, що ви типово бачитимете безпосередньо після виконання git init. Файл description використовується тільки програмою GitWeb, не звертайте на нього увагу. Файл config містить конфігураційні параметри, специфічні саме для конкретного репозиторія, а в теці info знаходиться файл з глобальними налаштуваннями ігнорування файлів — він дозволяє виключити шляхи, які ви не бажаєте додавати у файл .gitignore. Тека hooks містить клієнтські та серверні гаки, які були детальніше розглянуті у розділі Гаки (hooks) Git.

Лишилися ще чотири важливі елементи: файли HEAD та (ще не створений) index, і теки objects та refs. Це основні складові Git. У теці objects зберігається увесь вміст вашої бази даних, тека refs містить вказівники на об’єкти комітів у цих даних (гілки, теґи, віддалені гілки тощо), файл HEAD указує на поточну гілку — на яку ви зараз переключені, а у файлі index зберігається вміст індексу. Тепер ми детально розберемося з цими елементами, щоб зрозуміти як працює Git.