Асновы Git

Такім чынам, што ж такое Git, калі ў двух словах? Гета вельмі важны для засваення раздзел, таму што калі вы зразумееце што такое Git і фундаментальныя асновы таго як ён працуе, то эфектыўнае выкарыстанне Git можа стаць значна больш простым для вас. Пад час вывучэння Git пастарайцеся не абапірацца на ўспаміны пра іншыя СКВ, кшталту Subversion і Perforce, гэта дапаможа пазбегнуць памылак і разгубленасці пад час выкарыстання гэтай прылады. Git захоўвае інфармацыю і успрымае яе вельмі непадобна на іншыя сістэмы, нават не гледзячы на даволі блізкае падабенства карыстальніцкага інтэрфейсу. Разуменне гэтых адрозненняў дапаможа прадухіліць памылкі і разгубленасць пад час работы з Git.

Здымкі, а не адрозненні

Асноўнае адрозненне Git ад любой іншай СКВ (уключаючы Subversion і кампанію) — тое як Git ўяўляе сабе дадзеныя, якіе захоўвае. Канцэптуальна, большасць іншых сістэм захоўвае інфармацыю ў выглядзе набор змяненнеў. Гэтыя сістэмы (CVS, Subversion, Perforce, Bazaar і гэтак далей) ставяцца да інфармацыі, якую яны захозваюць, як да набора адрозненняў для кожнага з файлаў у параўнанні з папярэднім станам, як гэта паказана на Малюнку 1-4.

Малюнак 1-4. Іншыя сістэмы звычайна захоўваюць дадзеныя ў выглядзе набора зменаў для базавай версіі кожнага файла.

Git ўспрымае данныя ў сховішчы інакш. Замест таго, каб успрымаць іх як наборы зменаў, Git ставіцца да дадзеных хутчэй як да набора здымкаў стану невялікай файлавай стэмы. Кожны раз, калі вы захоўваеце дадзеныя вашага праекду ў Git, ён па-сутнасці, робіць здымак таго, як вашыя файлы выглядаюць ў гэты момант і спасылку на гэты здымак. Для павышэння эфектыўнасці, калі файл не змяняўся, то Git не захоўвае яго яшчэ раз, а проста робіць спасылку на яго папярэдні стан, які ўжо быў захаваны. Гіт успрымае дадзеныя больш падобна на тое, што паказана на Малюнку 1-5.

Малюнак 1-5. Git захоўвае дадзеныя як здымкі стану праекта пэўнага часу.

Гэта вельмі сур'ёзна адрознівае Git ад практычна ўсіх іншых СКВ. Гэта вымушае Git пераглядзець амаль усе аспекты кіравання версіямі, якія большасць іншых сістэм узялі з сістэм папярэдняга пакалення. Гэта робіць Git больш падобным на невялікую файлавую сістэму з неверагодна магутнымі прыладамі, створанымі каб працаваць павер яе, чым на звычайную СКВ. Некаторыя з пераваг, які дае такі падыход да захоўвання дадзеных, мы разгледзім ў Раздзеле 3, пад час вывучэння працы з галінамі.

Практычна ўсе аперацыі выконваюцца лакальна

Большасць аперацый у Git патрабуюць для працы толькі лакальныя файлы і рэсурсы, бо звычайна інфармацыя з іншых кампутараў у сетцы не патрэбныя. Калі вы карысталіся ЦСКВ, дзе большасць аперацый маюць дадатковыя затрымкі, звязаныя з працай праз сець, то гэты аспект Git прымусіць думаць, што богі хуткасці блаславілі гэтую сістэмы неверагоднымі здольнасцямі. Большасць аперацый выглядае практычна імгненнымі, паколькі ўся гісторыя праекта захоўваецца непасрэдна на вашым лакальным дыску.

Напрыклад, каб паглядзець гісторыю праекта Git не трэба звяртацца да сервера, каб атрымаць гісторыю і адлюстраваць яе для вас — можна проста прачытаць яе непасрэдна з вашай лакальнай базы дадзеных. Гэта значыць, што вы убачыце гісторыю праекта практычна імгненна. Калі вы захацелі ўбачыць розніцу паміж бягучай версіяй файла і той, што была месяц таму, Git можа праглядзець файл месячнай даўніны і вылічыць розніцу паміж версіямі лакальна, замест таго капрасіць у сервера зрабіць гэта, альбо выцягваць старую версію з сервера і потым зноўку ж вылічваць розніцу лакальна.

Да таго ж, гэта значыць што вельмі няшмат чаго нельга зрабіць калі вы па-за сеткай ці VPN. Калі вы ў самалёце ці ў цягніку і хочаце крыху папрацаваць, то вы можаце захоўваць праект ў СКВ (ці рабіць каміты, як яшчэ кажуць) без аніякіх праблем і перашкод ажно пакуль не з'явіцца сетка, з дапамогай якой вы зможаць выгрузіць змены. Калі вы прыйшлі дадому не і здолелі наладзіць VPN, вы ўсё яшчэ ў стане працаваць. У многіх іншых сістэмах вельмі цяжка, калі наогул магчыма рабіць так. У Perforce, напрыклад, вы няшмат што можаць зрабіць, калі няма сувязі з серверам, а ў Subversion і CVS вы можаце рэдактаваць файлы, але не будзеце ў стане захаваць змены ў сваю базу дадзеных (паколькі сувязі з базай дадзеных няма). Можа гэта і не выглядае вялікім дасягненнем, але вы будзеце здзіўленыя, убачыўшы наколькі гэта можа змяніць справу.

Git падтрымлівае цэласнасць

Для ўсяго ў Git'е вылічваецца кантрольная сума перад тым, як захаваць і затым гэтая кантрольная сума выкарыстоўваецца як спалылка на аб'ект. Гэта значыць, што немагчыма змяніць змест якога-небудзь файла ці тэчкі, каб Git не даведаўся пра гэта. Гэты функцыянал убудаваны ў Git на самых нізкіх узроўнях і з'яўляецца неад'емнай часткай яго філасофіі. Вы не можаце згубіць інфармацыю пры перадачы ці атрыманні пашкоджаннага файла без таго, габ Git не змог выявіць гэтага.

Механізм, які выкарыстоўвае Git для вылічэнне кантрольнай сумы называецца SHA-1 хэш. Гэта страка з 40 знакаў, складаючаяся з шастнадцацірычных знакаў (0-9 і a-f) і вылічваецца па зместу файла ці тэчкі, знаходзячыхся ў Git'е. SHA-1 хэш выглядае прыкладна так:

24b9da6552252987aa493b52f8696cd6d3b00373

Вы будзеце бачыць гэтыя хэшы паўсюль у Git'е тамушта ён выкарыстоўвае іх так шмат. Фактычна, Git захоўвае ўсё не па імені, у базе дадзеных адрасацыя адбываецца па значэнні хэша кантэнту.

Git як правіла, толькі дадае дадзеныя

Калі вы робіце дзеянні ў Git, амаль усе з іх толькі дадаюць дадзеныя ў базу дадзеных. Вельмі цяжка як-небуць прымусіць сістэму зрабіць нешта, што немагчыма адмяніць або прымусіць яе сцерці дадзеныя. Як і ў любой СКВ, вы можаце страціць або сапсаваць змены, якія вы яшчэ не зафіксавалі; але пасля таго як вы зафіксавалі здымак ў Git, вельмі цяжка страціць, асабліва калі вы рэгулярна змяшчаеце вашу базу дадзеных на іншы рэпазітар.

Гэта робіць працу з Git радасцю, таму што мы ведаем, што можам эксперыментаваць без небяспекі моцна сапсаваць становішча. Для больш глыбокага погляд на тое, як Git захоўвае свае дадзеныя і як вы можаце аднавіць дадзеныя, якія здаюцца страчанымі, глядзіце "Пад вокладкай" у главе 9.

Тры станы

Цяпер, звярніце ўвагу. Гэта галоўнае, што вам трэба памятаць аб Git, калі вы хочаце, каб астатак вашага навучальнага працэсу прайшоў гладка. У Git ёсць тры асноўныя станы, у якіх вашы файлы могуць знаходзіцца: зафіксаваны, зменены, і падрыхтаваныя. Зафіксаваны значыць, што дадзеныя бяспечна захаваны ў вашу лакальную базу дадзеных. Зменены значыць, што вы змянілі файл, але яшчэ не зафіксавалі ў вашай базе дадзеных. Падрыхтаваны значыць, што вы адзначылі зменены файл для ўключэння ў наступны каміт.

Такім чынам ёсць тры часткі у праекце з выкарыстаннем Git: каталог Git (the Git directory), працоўны катлог (the working directory), і вобласць падрыхтаваных файлаў (the staging area).

Малюнак 1-6. Працоўны каталог (the working directory), вобласць падрыхтаваных файлаў(the staging area), і каталог Git(the Git directory).

У каталозе Git захоўваюцца метаданныя і аб'екты базы дадзеных вашага праекту. Гэта найбольшая важная частка Git, і гэта менавіта тое, што капіруецца, калі вы кланіруеце рэпазітар з другога кампутара.

Працоўны каталог - гэта копія пэўная версіі праекта. Гэтыя файлы вымаюцца з сціснутай базы дадзеных у каталогу Git і размяшчаюцца на дыску, каб вы карысталіся імі ці змянялі.

Вобласць падрыхтаваных файлаў - гэта проста файл, звычайна змешчаны у каталогу Git, які захоўвае інфармацыю аб тым, што будзе выкарастана ў наступным каміце. Яго часам называюць індэксам, але становіцца стандартам называць яго вобласцю падрыхтаваных файлаў.

Стандартня праца з Git выглядае прыкладна так:

1. Вы змяняеце файлы ў вашым працоўным каталогу.
2. Вы падрыхтоўваеце файлы, дабаўляючы іх здымак у вашу вобласць падрыхтаваных файлаў.
3. Вы робіце каміт(фіксуеце), у выніку чаго здымак з вобласці падрыхтаваных файлаў захоўваецца ў вашым каталогу Git.

Калі бягучая версія файла супадае с той, што ў каталогу Git, файл знаходзіцца ў зафіксаваным стане. Калі файл зменены, але толькі дададзены ў вобласць падрыхтаваных файлаў, такі файл знаходзіцца ў падрыхтаваным стане. І калі файл был зменены пасля выгрузкі с базы дадзеных, але не дадзены ў вобласць падрыхтаваных файлаў, ён знаходзіцца ў змененым стане. У главе 2 вы даведаецеся больш аб гэтых станах і як выкарыстаць іх перавагі ці прапусціць частку падрытоўкі ўвогуле.