-
1. Начало
- 1.1 За Version Control системите
- 1.2 Кратка история на Git
- 1.3 Какво е Git
- 1.4 Конзолата на Git
- 1.5 Инсталиране на Git
- 1.6 Първоначална настройка на Git
- 1.7 Помощна информация в Git
- 1.8 Обобщение
-
2. Основи на Git
-
3. Клонове в Git
-
4. GitHub
-
5. Git инструменти
- 5.1 Избор на къмити
- 5.2 Интерактивно индексиране
- 5.3 Stashing и Cleaning
- 5.4 Подписване на вашата работа
- 5.5 Търсене
- 5.6 Манипулация на историята
- 5.7 Мистерията на командата Reset
- 5.8 Сливане за напреднали
- 5.9 Rerere
- 5.10 Дебъгване с Git
- 5.11 Подмодули
- 5.12 Пакети в Git (Bundling)
- 5.13 Заместване
- 5.14 Credential Storage система
- 5.15 Обобщение
-
6. Настройване на Git
- 6.1 Git конфигурации
- 6.2 Git атрибути
- 6.3 Git Hooks
- 6.4 Примерна Git-Enforced политика
- 6.5 Обобщение
-
7. Git и други системи
- 7.1 Git като клиент
- 7.2 Миграция към Git
- 7.3 Обобщение
-
8. Git на ниско ниво
- 8.1 Plumbing и Porcelain команди
- 8.2 Git обекти
- 8.3 Git референции
- 8.4 Packfiles
- 8.5 Refspec спецификации
- 8.6 Транспортни протоколи
- 8.7 Поддръжка и възстановяване на данни
- 8.8 Environment променливи
- 8.9 Обобщение
-
9. Приложение A: Git в други среди
-
10. Приложение B: Вграждане на Git в приложения
- 10.1 Git от команден ред
- 10.2 Libgit2
- 10.3 JGit
- 10.4 go-git
- 10.5 Dulwich
-
A1. Приложение C: Git команди
- A1.1 Настройки и конфигурация
- A1.2 Издърпване и създаване на проекти
- A1.3 Snapshotting
- A1.4 Клонове и сливане
- A1.5 Споделяне и обновяване на проекти
- A1.6 Инспекция и сравнение
- A1.7 Дебъгване
- A1.8 Patching
- A1.9 Email команди
- A1.10 Външни системи
- A1.11 Административни команди
- A1.12 Plumbing команди
1.1 Начало - За Version Control системите
Тази глава ще ви помогне да започнете с Git. Ще стартираме с малко история на инструментите за контрол на версиите, след това ще продължим с инсталирането на Git във вашата система и накрая ще видим как да започнем да работим с нея. В края на тази глава би следвало да сте наясно защо е създаден Git, защо е добре да го използвате и как да започнете
За Version Control системите
Какво е “version control” и защо ви интересува? Системата за контрол на версиите е средство за проследяване и запис на промените по файл (или множество файлове) във времето, така че да можете да възстановите произволна версия на файла/файловете във всеки един момент по-късно. За примерите в тази книга, вие ще използвате софтуерен код под формата на файлове, чиито версии ще бъдат контролирани, макар в действителност да можете да правите това с произволен тип файл във вашия компютър.
Ако сте графичен или уеб дизайнер и желаете да пазите всяка версия на дадено изображение или layout (а е доста вероятно да искате), то Version Control системата (VCS) е мъдър избор за вас. Тя ви позволява да възстановите файловете си обратно към определен момент от миналото, да възстановите цял проект към даден предишен момент, да сравнявате промените във времето, да видите кой последно е променил нещо, което би могло да предизвика проблем, кой и кога е съобщил за грешка и т.н. Използването на VCS също така означава, че ако случайно объркате нещата и неволно загубите файлове - можете лесно да ги възстановите. Не на последно място - получавате всичко това на цената на съвсем малко изразходвани ресурси.
Локални Version Control Systems
Много хорат предпочитат да реализират контрол на версиите като просто копират файловете в друга директория (ако са достатъчно изобретателни - посочвайки дата и час в името ѝ). Този начин е често използван защото е много прост, но и също толкова податлив на грешки. Много лесно е да забравите в коя директория сте в момента и неволно да запишете в грешен файл или пък да копирате погрешни файлове не където трябва.
За да се справят с това неудобство, програмистите отдавна разбработиха локални VCS с прости бази данни, които съхраняваха промените по файловете, които се проследяват.
Една от най-популярните подобни системи се нарича RCS и все още се разпространява с много компютри и до днес. RCS работи съхранявайки множество от пачове (разликите във файловете) в специален формат на диска и може да възстанови състоянието на файла към произволен момент добавяйки всички тези пачове.
Централизирани Version Control Systems
Следващото голямо предизвикателство пред разработчиците дойде в момента, когато се оказа, че те трябва да работят съвместно с други такива, на други компютри. За да се справят с това, бяха разработени централизираните Version Control системи (CVCS). Тези системи - CVS, Subversion, Preforce, използват един сървър, съдържащ всички контролирани файлове и множество от клиенти, които издърпват файловете от това централно място. В продължение на много години това беше стандарт за контрол на версиите.
Този подход предлага много предимства, особено спрямо локалните VCS. Например, всеки участник в проекта е запознат в доста добра степен на достоверност какво друг е правил по него. Администраторите имат подробен контрол върху това кой какво може да прави и освен това е много по-лесно да се администрира CVCS отколкото локалните бази данни на всеки клиент.
Обаче, този подход си има и сериозни недостатъци. Най-очевидният от тях е, че всички данни се пазят на едно място и зависят от надеждността на сървъра, който ги съхранява. Ако сървърът по някаква причина не е достъпен за час - тогава през този час никой не може да качва своите промени. Ако, в най-лошия случай, се повреди диск на сървъра и не разполагате с адекватни архиви - губите абсолютно всичко, цялата история на проекта, освен ако някой потребител няма snapshot на проекта на локалния си компютър. Локалните VCS системи са изложени на същия риск — ако цялата история на проекта се пази само на едно място, рискувате да го загубите изцяло.
Разпределени Version Control Systems
Тук е мястото, където се намесват разпределените (Distributed) Version Control системи (DVCS). В DVCS (каквито са Git, Mercurial, Bazaar или Darcs), клиентите не просто изтеглят последния snapshot на файловете - те изцяло клонират цялото хранилище, включително пълната му история. По този начин, ако сървърът загине, хранилището на даден проект може да се възстанови от локалното копие на всеки клиент. Всяко копие по същество е пълен архив на всички данни.
В допълнение, много от тези системи се справят доста добре със задачата да могат да обслужват няколко отдалечени хранилища, така че можете да си сътрудничите с различни групи от разработчици едновременно, в рамките на един и същи проект. Това позволява да създадете няколко различни работни потока, което е невъзможно в централизираните системи като йерархични модели.
