Git
Chapters ▾ 2nd Edition

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

Какво е Git

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

Snapshot-и вместо разлики

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

Съхраняване на данните като списък от промени в базовата версия на всеки от файловете.
Figure 4. Съхраняване на данните като списък от промени в базовата версия на всеки от файловете.

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

Git пази данните като поток от snapshot-и във времето.
Figure 5. Записане на данните като поток от snapshot-и във времето.

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

Почти всяка операция е локална

Повечето операции в Git се нуждаят само от локални файлове и ресурси - общо взето не се нуждаете от информация намираща се в мрежата. Ако сте ползвали CVCS, където производителността на повечето операции зависи от мрежата, ще си помислите, че боговете на скоростта са благословили 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. Трудно е да накарате системата да направи каквото и да е без то да може да бъде възстановено или пък да изтриете данни безвъзвратно. Разбира се, подобно на всяка друга VCS, вие можете да загубите или объркате промените, които не са били къмитнати, но веднъж направили snapshot-а в Git - е много трудно да загубите данни, особено пък ако редовно изпращате базата си към отдалечено хранилище.

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

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

  • Променен (modified) означава, че сте променили файла, но той все още не е къмитнат в локалната база данни.

  • Статусът индексиран (staged), означава че сте маркирали променен файл в текущия му вариант, указвайки на Git да го включи в следващия къмитнат snapshot.

  • Къмитнат (commited) означава, че данните са надеждно записани в локалната ви база данни.

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

Работна област, staging област и Git директория.
Figure 6. Работна област, staging област и Git директория.

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

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

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

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

  1. Вие променяте файлове в работната област.

  2. Вие селективно индексирате (stage-вате) само промените, които искате да са част от следващия ви къмит.

  3. Вие правите къмит, при което файловете се вземат така както изглеждат в staging областта и този snapshot се записва за постоянно във вашата Git директория.

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