-
1. Начало
- 1.1 За Version Control системите
- 1.2 Кратка история на Git
- 1.3 Какво е Git
- 1.4 Конзолата на Git
- 1.5 Инсталиране на Git
- 1.6 Първоначална настройка на Git
- 1.7 Помощна информация в Git
- 1.8 Обобщение
-
2. Основи на Git
-
3. Клонове в Git
-
4. GitHub
-
5. Git инструменти
- 5.1 Избор на къмити
- 5.2 Интерактивно индексиране
- 5.3 Stashing и Cleaning
- 5.4 Подписване на вашата работа
- 5.5 Търсене
- 5.6 Манипулация на историята
- 5.7 Мистерията на командата Reset
- 5.8 Сливане за напреднали
- 5.9 Rerere
- 5.10 Дебъгване с Git
- 5.11 Подмодули
- 5.12 Пакети в Git (Bundling)
- 5.13 Заместване
- 5.14 Credential Storage система
- 5.15 Обобщение
-
6. Настройване на Git
- 6.1 Git конфигурации
- 6.2 Git атрибути
- 6.3 Git Hooks
- 6.4 Примерна Git-Enforced политика
- 6.5 Обобщение
-
7. Git и други системи
- 7.1 Git като клиент
- 7.2 Миграция към Git
- 7.3 Обобщение
-
8. Git на ниско ниво
- 8.1 Plumbing и Porcelain команди
- 8.2 Git обекти
- 8.3 Git референции
- 8.4 Packfiles
- 8.5 Refspec спецификации
- 8.6 Транспортни протоколи
- 8.7 Поддръжка и възстановяване на данни
- 8.8 Environment променливи
- 8.9 Обобщение
-
9. Приложение A: Git в други среди
-
10. Приложение B: Вграждане на Git в приложения
- 10.1 Git от команден ред
- 10.2 Libgit2
- 10.3 JGit
- 10.4 go-git
- 10.5 Dulwich
-
A1. Приложение C: Git команди
- A1.1 Настройки и конфигурация
- A1.2 Издърпване и създаване на проекти
- A1.3 Snapshotting
- A1.4 Клонове и сливане
- A1.5 Споделяне и обновяване на проекти
- A1.6 Инспекция и сравнение
- A1.7 Дебъгване
- A1.8 Patching
- A1.9 Email команди
- A1.10 Външни системи
- A1.11 Административни команди
- A1.12 Plumbing команди
8.1 Git на ниско ниво - Plumbing и Porcelain команди
Може да сте стигнали до тази глава прескачайки директно от много по-ранна такава, а може и да сте изчели последователно всичко до тук — и в двата случая стигаме до мястото, в което ще разгледаме как работят вътрешните механизми на Git. Като автори на книгата сме на мнение, че информацията в следващите секции е фундаментално важна, ако искате да оцените изцяло колко полезен и мощен инструмент е Git. От друга страна обаче стоят опасенията, че тази информация може да е смущаваща и ненужно сложна за начинаещите. По тази причина решихме, че е добре главата да е последна в книгата и оставяме на читателя да прецени кога да я прочете.
След като сме стигнали дотук, нека започнем. Първо, да припомним отново, че Git фундаментално представлява вид файлова система, позволяваща адресиране на съдържание, с VCS интерфейс написан върху нея. Ще научим повече за това след малко.
В ранните версии на Git (преди версия 1.5), потребителският интерфейс беше значително по-сложен, понеже ударението беше върху функционалностите на файловата система, вместо върху една по-полиранa VCS. В последните няколко години потребителският интерфейс претърпя значителни подобрения, сега е много изчистен и лесен за ползване, въпреки че старите стереотипни схващания за ранните трудни и сложни за овладяване UI версии, все още витаят наоколо.
Content-addressable filesystem слоят на Git е изключително впечатляващ аспект от системата, така че ще започнем с него, а след това ще разгледаме транспортните механизми и възможностите за поддръжка на хранилищата, с които евентуално бихте имали нужда да работите.
Plumbing и Porcelain команди
В книгата дотук използвахме около 30 на брой подкоманди на Git като checkout
, branch
, remote
, и т.н.
Но понеже Git отначало беше само набор от инструменти за контрол на версиите, вместо пълнофункционална user-friendly VCS, тя разполага с много подкоманди, които вършат работата на ниско ниво и са проектирани да се използват взаимно в UNIX-стил или да бъдат извиквани от скриптове.
Тези команди от по-ниско ниво в Git се наричат “plumbing” команди, докато по-потребителски ориентираните са получили наименованието “porcelain” команди.
Както виждате, в деветте глави дотук, работихме почти само с porcelain командите. В тази глава обаче, акцентът ще е върху plumbing командите, които дават достъп до вътрешните Git механизми и демонстрират как и защо Git се справя със задачите си. Много от тези команди не са предназначени за ръчно използване от командния ред, вместо това те са подходящи за градивни елементи в множество странични инструменти и специфични скриптове.
Изпълнявайки git init
в дадена директория, Git създава поддиректорията .git
, която пази почти всичко, което системата съхранява и манипулира.
Ако искате да архивирате или клонирате вашето хранилище, то копирането на тази единична директория ви дава почти всичко необходимо за целта.
Цялата тази глава от книгата се занимава със съдържанието на въпросната директория.
Ето как изглежда една току що инициализирана .git
директория:
$ ls -F1
config
description
HEAD
hooks/
info/
objects/
refs/
В зависимост от версията на Git, може да видите и допълнителни неща тук, но в общи линии това е прясно git init
хранилище.
Файлът description
се използва само от програмата GitWeb, не ни засяга в момента.
Файлът config
пази конфигурационните опции за конкретния проект, а директорията info
съдържа глобалния exclude файл за игнориране на пътища, които не искате да вмъквате в .gitignore
файл.
Директорията hooks
съхранява клиентските и сървърни hook скриптове, на които обърнахме внимание в Git Hooks.
Остават четири важни елемента: HEAD
и (все още липсващите) index
файлове и директориите objects
и refs
.
Именно тези елементи са в ядрото на Git.
Директорията objects
пази цялото съдържание на вашата база данни, директорията refs
съхранява указатели в къмит обекти в тези данни (клонове, тагове, remotes и др.). Файлът HEAD
сочи към клона, съдържанието на който текущо е извлечено в работната директория, а файлът index
е мястото, където Git пази информацията от индексната област.
Сега ще разгледаме всеки от тези елементи в детайли.