Основи на Git
Во неколку збора, што е Git? Оваа секција е многу битно да ја разберете, бидејќи ако разберете што е Git и основите како работи, тогаш ефикасното користење на Git веројатно ќе биде многу едноставно за вас. Додека учите за Git, пробајте да ги изолирате работите што евентуално ги знаете за другите VCS, како што е Subversion и Perforce; на тој начин ќе ја избегнете забуната при користењето на алатката. Git ги складира и обработува информациите многу поразлично од другите системи, иако корисничкиот интерфејс е прилично сличен; доколку ги разберете тие разлики ќе ги избегнете забуните при неговото користење.
Целосни слики, наместо закрпи
Најголемата разлика помеѓу Git и било кој друг VCS (Subversion и сл.) е во начинот на кој Git ги обработува податоците. Концептуално, повеќето други системи информациите ги складираат како листа од промени над поединечните датотеки. Тие системи (CVS, Subversion, Perforce, Bazaar итн) информациите ги чуваат како множества од датотеки и промените настанати над тие датотеки со текот на времето, како што е прикажано на Слика 1-4.
Слика 1-4. Другите системи чуваат закрпи за секоја датотека.
Git не ги третира или чува податоците на тој начин. Наместо тоа, Git податоците ги третира како множества од целосни слики/копии од мини фајлсистем. Секогаш кога сакате да ја зачувате состојбата во која се наоѓа проектот во Git, тој едноставно прави слика од тоа како изгледаат сите датотеки во тој момент и зачувува референца до таа слика. За да биде ефикасен, доколку датотеките не се променети, Git не прави копија од датотеките туку само прави линк до претходно зачуваната идентична датотека. Git ги третира податоците како што е прикажано на сликата 1-5.
Слика 1-5. Git ги зачувува податоците како целосни копии од проектот.
Ова е битна разлика помеѓу Git и речиси сите други VCS. Со тоа Git ги преиспитува речиси сите аспекти од системите за контрола на верзиите, за разлика од другите системи кои што едноставно ги копирале од претходните генерации. Тоа го прави Git да личи помалку на мини фајлсистем со извонредно моќни алатки над него, отколку како едноставен VCS. Ќе ги истражиме придобивките од таквото третирање на податоците при обработка на гранањето во Git во Поглавје 3.
Речиси секоја операција е локална
За повеќето операции што ги изведува Git му се потребни само локални датотеки и ресурси - генерално никакви информации од друг компјутер на мрежата не се потребни. Ако сте навикнати на користење на CVCS каде што повеќето операции имаат мрежна латенција, овој аспект на Git ќе ве натера да си помислите дека боговите на брзината го надариле Git со неискажлива моќ. Бидејќи целосниот историјат од проектот го имате локално на вашиот хард диск, повеќето операции изгледаат речиси моментални.
На пример, за да ја прегледате историјата на проектот, Git не треба да оди до серверот за да ја земе историјата и да ви ја прикаже - туку едноставно ја чита директно од вашата локална база на податоци. Тоа значи дека историјатот на проектот го гледате речиси моментално. Доколку сакате да ги видите разликите помеѓу сегашната верзија на некоја датотека и верзијата од пред еден месец, Git може да ја види состојбата на датотеката од пред еден месец и локално да ви ги пресмета разликите, наместо да испрати барање за тоа до оддалечен сервер, или пак да побара постара верзија за датотеката од некој сервер за да ја пресмета разликата локално.
Тоа значи дека нема многу работи кои што нема да може да ги направите доколку сте офјалн или не сте на VPN. Доколку се качите на авион или воз, и сакате малку да поработите, можете да правите нови состојби од проектот (commit) се додека не добиете мрежна врска и тогаш ќе ги аплоадирате. Ако сте дома и не може да го натерате вашиот VPN клиент да проработи, сепак можете да си работите на проектот. Кај многу други системи, ваквиот начин на работа или е невозможен или многу тешко изводлив. Со Perforce, на пример, речиси ништо не можете да правите доколку немате конекција со серверот; кај Subversion и CVS, може да ги едитирате датотеките, меѓутоа не може да направите нова состојба од проектот (commit) бидејќи базата на податоци е на сервер. Можеби сето ова не изгледа како некоја голема работа, меѓутоа може да се изненадите колкава разлика може да ви направи.
Git има интегритет
Пред да се зачуваат работите во Git, им се пресметува контролна сума, а подоцна истите работи се референцираат преку таа сума. Тоа значи дека е невозможно да се промени содржината на некоја датотека без Git да дознае за тоа. Тоа функционалност е вградена во Git во најниските нивоа и е интегрален дел од неговата филозофија. Не може да изгубите информација при пренос или да имате корумпирана датотека без Git да го детектира тоа.
Механизмот кој што го користи Git за пресметување на контролната сума се вика SHA-1 хеш. Тоа е стринг од 40 знаци составен од хексадекадни знаци (0-9 и a-f) и се пресметува врз основа на содржината на датотеката или папката во Git. SHA-1 хешот изгледа отприлика вака:
24b9da6552252987aa493b52f8696cd6d3b00373Насекаде ќе ги гледате ваквите хеш вредности во Git затоа што тој насекаде ги користи. Всушност, Git сите работи ги зачувува не според името на датотеката, туку во база на податоци која е адресабилна според хеш вредноста на нивната содржина.
Во основа Git само додава податоци
Кога изведувате операции во Git, речиси сите тие само додаваат податоци во Git базата на податоци. Речиси е невозможно да го натерате системот да направи нешто што подоцна не може да се врати на претходната состојба, или пак да го натерате да избрише некои податоци. Како и со секој VCS, може да ги загубите податоците кои што не сте ги комитувале; но откако ќе ги комитувате и кога Git ќе направи слика од тоа, тогаш навистина е тешко да загубите нешто, особено доколку редовно вашата база ја синхронизирате (push) со друго репозитори.
Тоа го прави користењето на Git вистинско задоволство бидејќи знаеме дека може да експериментираме без притоа да се плашиме дека може да ги уништиме работите. Поде-тално за тоа како Git ги складира податоците и како може да ги реставрирате податоците кои изгледаат дека се загубени погледнете во “Под хаубата” во поглавје 9.
Трите нивоа
Сега внимавајте. Ова е главната работа што треба да се запомни за Git доколку сакате понатамошниот процес на учење да ви оди лесно. Git има три нивоа во кои што може да се најдат датотеките: комитувани (committed), променети (modified) и поставени (staged). Комитувани значи дека податоците безбедно се зачувани во локалната база на податоци. Променети значи дека датотеките се променети, меѓутоа сеуште не се комитувани. Поста-вени (staged) значи дека сте ги маркирале променетите датотеки во нивната тековна состојба да бидат зачувани во следниот комит.
Тоа не води до главните три секции од еден Git проект: Git папката, работна папка, и сцена (staging area).
Слика 1-6. Работна папка, сцена, и git папката.
Git папката е местото каде што Git ги складира мета-податоците и базата на податоци за вашиот проект. Тоа е најзначајниот дел од Git, и тоа е она што се копира кога клонирате репозитори од друг компјутер.
Работната папка е поглед (checkout) на една верзија/состојба од проектот. Датотеките се извлечени од компресираната база на податоци од Git папката и се поставени на хард дискот за да ги користите или менувате.
Сцена (staging area) е едноставна датотека, обично е сместена во Git папката, и во неа се наоѓаат информации за тоа што ќе оди во следниот комит. Понекогаш за ова се користи терминот индекс (index), но се поприфатен термин е да се нарекува сцена (staging area).
Вообичаениот начин на работа со Git отприлика изгледа вака:
1. Ги менувате датотеките од вашата локална папка.
- Ги поставувате датотеките на сцена, т.е. се прават слики од нив и се додаваат на сцената (staging area).
- Правите комит, кој што ги зема датотеките како што се поставени на сцената и таа слика перманентно ја зачувува во локалната Git папка.
Ако одредена верзија од датотеката се наоѓа во git папката, тогаш таа се смета за комитува-на. Доколку датотеката е променета и ако е додадена на сцена (staging area) тогаш таа се наоѓа во нова состојба - staged. Доколку пак датотеката е променета во однос на тоа кога е направен нов поглед во Git (checkout), и доколку променетата состојба не е додадена на сцена, тогаш датотеката едноставно се наоѓа во состојба која се нарекува променета. Во поглавје 2, ќе научите повеќе за тие состојби и како истите да ги искористите, или пак комплетно да го прескокнете чекорот од додавање на датотеката на сцена.