8.6 Git на ниско ниво - Транспортни протоколи

Ако настройвате хранилище само за четене през HTTP, тогава dumb протоколът е вероятния избор. Този вид протокол се нарича “dumb”, защото не изисква Git-specific код от страна на сървъра по време на транспортния процес. Процесът е серия от HTTP GET заявки, при които клиентът може да предположи какво е разположението на Git хранилището в сървъра.

Нека преминем през http-fetch процеса за библиотеката simplegit:

Първото нещо, което прави командата, е да изтегли файла info/refs. Този файл се записва от командата update-server-info, ето защо трябва да разрешите това като post-receive hook за да може HTTP транспорта да работи коректно:

Сега имате списък на отдалечените референции и SHA-1 стойности. След това поглеждаме към какво сочи референцията HEAD, така че да знаем какво да извлечем в работната директория, когато сме готови:

Това значи, че ще разпакетираме клона master в края. В този момент сме готови да пуснем процеса. Понеже изходната точка е къмит обекта ca82a6, който виждаме във файла info/refs, започваме с неговото изтегляне:

Получаваме обратно обект — този обект е в loose формат на сървъра и сме го изтеглили през статична HTTP GET заявка. Можете да използвате zlib за да го декомпресирате, да премахнете хедъра и да видите съдържанието на къмита:

Следва да се изтеглят още два обекта — cfda3b, което е дървото на съдържанието, към което сочи току що изтегления къмит, и родителския къмит 085bb3:

Това ни дава следващия къмит обект. Изтегляме tree обекта:

Получаваме отговор 404 — изглежда, че tree обектът не е в loose формат на сървъра. За това може да има различни причини — обектът може да е в алтернативно хранилище или пък може да е в packfile в текущото. Git първо проверява за евентуални заместители:

Ако получим списък от алтернативни URL-и, Git проверява за loose файлове и packfile файлове в тях — това е чудесен начин за проекти, които са forks на други да споделят обекти на диска. Само че, в този случай нямаме такъв списък, така че обектът трябва да е пакетиран в packfile. За да видим какви packfiles са налични на сървъра трябва да вземем файла objects/info/packs, който съдържа списък с тях (генерира се също от update-server-info):

Има само един packfile на сървъра, така че обектът очевидно е там, но все пак проверяваме и в индекса за да се уверим в това. Такава проверка е полезна и ако имате повече packfiles на сървъра за да намерите кой точно от тях съдържа търсения обект:

Сега имаме packfile индекса и можем да видим дали обектът ни е посочен в него, индексът съдържа списък с SHA-1 чексумите и позициите (отместванията) на обектите от packfile файловете. Обектът ни е тук и следва да изтеглим целия packfile:

Получихме tree обекта и можем да продължим стъпките през къмитите. Те също са в packfile пакета, който току що изтеглихме, така че не се налага да правим повече заявки към сървъра. Git извлича работно копие от клона master, към който сочеше HEAD референцията изтеглена в началото.

Протоколът dumb е прост, но не много ефективен и освен това не може да обслужва изпращането на данни от клиента към сървъра. Протоколът smart е много по-подходящ за трансфер на данни, но изисква процес в отдалечената страна на връзката, който да е запознат с Git — той трябва да може да прочита локалните данни, да определи какво има и от какво се нуждае клиента и да му генерира custom packfile като резултат. Съществуват две множества процеси за трансфер на данни: чифт за изпращане и още един чифт за приемане.

Тази секция съдържа много съкратен преглед на транспортните протоколи. Протоколът включва и много други възможности като multi_ack или side-band поддръжка, но те са извън темата за книгата. Опитахме да опишем основната идея в механизмите на комуникацията между клиент и сървър, ако се нуждаете от повече подробности, може да разгледате сорс кода на Git.