1.3 Начало - Какво е Git

Основната разлика между Git и другите системи за контрол на версиите е начинът, по който Git третира данните. Концептуално, повечето други системи записват информацията като списък от файлово-базирани промени. Тези системи (CVS, Subversion, Perforce, Bazaar) виждат информацията, която съхраняват като колекция от файлове и промените направени във файловете във времето (известно още като delta-based version control).

Git обаче не третира информацията така. Вместо това, Git възприема своите данни по-скоро като колекция от snapshots (моментни снимки на статуса) на една миниатюрна файлова система. Всеки път, когато къмитвате или записвате статуса на вашия проект в Git, системата най-общо казано прави снимка на това как изглеждат файловете ви в този момент и съхранява референция към този snapshot. За ефективност, ако някои файлове не са променени, Git не ги записва отново, а просто записва указател към предишния идентичен файл, който вече е съхранил. Така че - Git възприема своите данни като поток от snapshot-и.

Това е важна разлика между Git и почти всички други VCS. Git променя почти всеки един аспект на контрола на версиите, работейки подобно на малка файлова система с мощни инструменти, вместо да бъде просто VCS. Ще разгледаме някои от предимствата, които дава тази концепция в главата посветена на клоновете код - Клонове в Git.

Повечето операции в Git се нуждаят само от локални файлове и ресурси - общо взето не се нуждаете от информация намираща се в мрежата. Ако сте ползвали CVCS, където производителността на повечето операции зависи от мрежата, ще си помислите, че боговете на скоростта са благословили Git с извънземни сили. Понеже разполагате с цялата история на проекта директно на диска, повечето операции изглеждат почти светкавични.

Например, за да ви покаже историята на проекта, Git не се нуждае да контактува със сървъра а просто чете директно от локалната си база данни и вие виждате историята почти незабавно. Ако желаете да видите промените в даден файл между текущата му версия и тази отпреди месец, Git ще направи локална калкулация на разликите, вместо да трябва да пита отдалечения сървър за това или да трябва да издърпва по-стара версия от сървъра и едва след това да калкулира разликите локално.

Това също значи, че можете да правите почти всичко когато сте офлайн или когато VPN връзката ви не работи например. Ако сте в самолет или влак и искате да свършите малко работа, можете спокойно да къмитвате промените си (в локалното си копие, нали запомнихте?) и когато имате мрежова връзка - да ги качите на сървър. Ако сте вкъщи и VPN клиентът ви не работи - вие можете да продължите работата си. В много други системи това е трудно или невъзможно. В Perforce например, не можете да направите много офлайн, а в Subversion и CVS можете да редактирате файлове, но не можете да къмитвате промените към базата данни (защото тя не е достъпна офлайн). Това може да не изглежда толкова важно, но ще се изненадате каква разлика в стила ви на работа може да направи.

Всичко в Git се проследява с чексуми преди да се запише и след това обръщенията към съдържанието стават чрез чек-сумите. Това означава, че е невъзможно да промените съдържанието на файл или директория без Git да знае за това. Тази функционалност е вградена в Git на най-ниско ниво и е интегрална част от философията на системата. Вие не можете да загубите информация в етапите на работа или да повредите файл без Git да го усети.

Механизмът, който Git използва за чек-сумите се нарича SHA-1 хеш. Това е 40-символен стринг съставен от шестнадесетични числа (0–9 и a–f) и калкулиран на базата на съдържанието на файл или структура на директория в Git. Един SHA-1 хеш може да изглежда подобно на това:

Ще срещате тези хешове почти навсякъде, защото Git ги ползва повсеместно. В действителност, Git пази обектите в базата си данни не по имена на файлове, а посредством хешираните стрингове отразяващи съдържанието им.

Когато правите нещо в Git, тези действия само добавят информация към базата данни на Git. Трудно е да накарате системата да направи каквото и да е без то да може да бъде възстановено или пък да изтриете данни безвъзвратно. Разбира се, подобно на всяка друга VCS, вие можете да загубите или объркате промените, които не са били къмитнати, но веднъж направили snapshot-а в Git - е много трудно да загубите данни, особено пък ако редовно изпращате базата си към отдалечено хранилище.

Това е хубавата страна на Git - знаем, че можем да експериментираме без опасност от тежки последствия. За повече информация относно това как Git съхранява своите данни и как можете да възстановите информация, която изглежда загубена, погледнете Възстановяване на направени действия.

Сега внимавайте! Това е най-важното, което трябва да помните за Git, ако искате да научите системата лесно. Git пази файловете ви в три възможни състояния: modified, staged и committed:

Това ни довежда до трите главни секции на един Git проект: работната област, staging областта и Git директорията.

Работната област е моментното състояние на дадена версия от проекта. Файловете в тази област се издърпват от компресираната база в Git директорията и се поставят на диска за да можете да ги променяте.

Staging областта представлява файл, който се пази в Git директорията и който пази информация за това какво ще отиде в следващия ви къмит. Понякога тази област бива наричана също и “индекс”, но по-често се нарича staging area.

Git директорията е мястото, където Git пази своите мета-данни и базата данни с обектите за вашия проект. Това е най-важната част на Git и е това, което се копира когато клонирате хранилище от отдалечен компютър.

Един типичен Git работен процес изглежда по подобен начин:

Ако дадена версия на определен файл се намира в Git директорията, тази версия се счита за къмитната. Ако файлът е променен и добавен в staging областта - той се разглежда като staged/индексиран. И ако файлът е променен откакто е издърпан, но не е бил индексиран - то той се счита за променен. В Основи на Git, ще научите повече за тези статуси на файловете ви и как да се възползвате от тях или пък директно да пропуснете staged-частта.