-
1. Почеток
- 1.1 За верзиска контрола
- 1.2 Кратка историја на Git
- 1.3 Основи на Гит
- 1.4 Командната линија
- 1.5 Инсталирање на Git
- 1.6 First-Time Git Setup
- 1.7 Getting Help
- 1.8 Заклучок
-
2. Основите на Git
-
3. Гранење во Git
- 3.1 Гранење објаснето
- 3.2 Основно разгранување и спојување
- 3.3 Branch Management
- 3.4 Работни процеси
- 3.5 Далечински гранки
- 3.6 Ребаза
- 3.7 Заклучок
-
4. Git на Сервер
- 4.1 Протоколите
- 4.2 Добивање на Git на сервер
- 4.3 Генерирање на вашиот SSH јавен клуч
- 4.4 Поставување на серверот
- 4.5 Гит демон
- 4.6 Smart HTTP
- 4.7 GitWeb
- 4.8 GitLab
- 4.9 Опции за домаќини на трети лица
- 4.10 Заклучок
-
5. Дистрибуиран Git
- 5.1 Дистрибуирани работни процеси
- 5.2 Придонес кон проект
- 5.3 Приватен мал тим
- 5.4 Одржување на проект
- 5.5 Заклучок
-
6. GitHub
-
7. Git Алатки
- 7.1 Revision Selection
- 7.2 Интерактивно стажирање
- 7.3 Stashing and Cleaning
- 7.4 Signing Your Work
- 7.5 Searching
- 7.6 Rewriting History
- 7.7 Reset Demystified
- 7.8 Напредно спојување
- 7.9 Rerere
- 7.10 Дебагирање со Git
- 7.11 Submodules
- 7.12 Збивање
- 7.13 Заменување
- 7.14 Складирање на ингеренции
- 7.15 Заклучок
-
8. Персонализација на Git
- 8.1 Git Configuration
- 8.2 Git Атрибути
- 8.3 Git Hooks
- 8.4 An Example Git-Enforced Policy
- 8.5 Заклучок
-
9. Git и други системи
- 9.1 Git како Клиент
- 9.2 Мигрирање кон Git
- 9.3 Заклучок
-
10. Внатрешноста на Git
- 10.1 Plumbing and Porcelain
- 10.2 Git Objects
- 10.3 Git References
- 10.4 Packfiles
- 10.5 The Refspec
- 10.6 Transfer Protocols
- 10.7 Maintenance and Data Recovery
- 10.8 Environment Variables
- 10.9 Заклучок
-
A1. Appendix A: Git во други околини
- A1.1 Graphical Interfaces
- A1.2 Git in Visual Studio
- A1.3 Git in Eclipse
- A1.4 Git in Bash
- A1.5 Git in Zsh
- A1.6 Git in Powershell
- A1.7 Заклучок
-
A2. Appendix B: Вметнување на Git во вашите апликации
- A2.1 Command-line Git
- A2.2 Libgit2
- A2.3 JGit
- A2.4 go-git
-
A3. Appendix C: Git команди
- A3.1 Setup and Config
- A3.2 Getting and Creating Projects
- A3.3 Basic Snapshotting
- A3.4 Branching and Merging
- A3.5 Sharing and Updating Projects
- A3.6 Inspection and Comparison
- A3.7 Debugging
- A3.8 Patching
- A3.9 Email
- A3.10 External Systems
- A3.11 Administration
- A3.12 Plumbing Commands
1.1 Почеток - За верзиска контрола
Ова поглавје ќе започне со Гит(Git). Ќе започнеме со објаснување на некоја позадина во алатките за верзиска контрола, потоа преминувајќи на инсталирањето на Git во вашиот компјутер и конечно како да го подесите за да започнете со работа. На крајот на ова поглавје треба да разберете што е Git, зашто треба да го користите и да можете да го користите ефикасно.
За верзиска контрола
Што е "верзиска контрола", и зошто треба да се грижите за тоа? Верзиска контрола е систем за евиденција на промени во еден фајл или колекција од фајлови во тек на време, со можноста за подоцна да се види специфична верзија. За примеритe во оваа книга, ќе го користите изворниот код на софтверот како фајлови под верзиска контрола, иако во реалноста тоа може да се направи со било кој тип на фајл на компјутер. Ако сте графички или веб-дизајнер и сакате да ја задржите секоја верзија на сликата или изгледот (што најверојатно сакате), Систем за контрола на верзии (VCS) многу мудро да се користи. Тоа ви овозможува да ги вратите избраните датотеки назад во претходната состојба, вратете го целиот проект назад во претходна состојба, да ги споредите промените со текот на времето, да видите кој последен пат го изменил нешто што може да предизвика проблем, кој вовел проблем и друго. Користењето на VCS, исто така, генерално значи дека ако ги затегнете работите или ги изгубите датотеките, лесно можете да закрепнете. Покрај тоа, ќе го добиете сето ова за многу малку над глава.
Локални системи за верзиска контрола
Методот за верзиска контрола на многу луѓе е да ги копираат фајловите во друг директориум (можеби директориум со временски печат, ако се паметни). Овој пристап е многу чест затоа што е толку едноставен, но исто така е неверојатно склон на грешки. Лесно е да се заборави во кој директориум сте и случајно да запишете во погрешна датотека или да копирате преку фајлови што не сакате да ги користите.
За да се справат со ова прашање, програмерите одамна развиле локални VCS-и кои имаат едноставна база на податоци која ги зачувува сите промени во фајлови под верзиска контрола.
![Дијаграм за локална верзиска контрола](png/local.png)
Една од популарните VCS алатки е системот наречен RCS, кој сеуште е вклучен со многу компјутери денес. RCS работи со одржување на вид на закрпа (разликите помеѓу две состојби) во посебен формат на дискот; тогаш може повторно да се рекреира било кој фајл во било кој момент со додавање или одзимање на закрпите до тој момент.
Централизирани системи за верзиска контрола
Следното големо прашање со кое луѓето се соочуваат е дека тие треба да соработуваат со друѓи луѓе. За да се справат со овој проблем, се развија Централизирани верзиски контролни системи (CVCS). Овие системи, како што се CVS, Subversion и Perforce, имаат единствен сервер кој ги содржи сите верзии на фајловите, како и голем број клиенти кои зимаат фајлови од тоа централно место. Многу години веќе, ова е стандард за верзиска контрола.
Многу години веќе, ова е стандард за верзиска контрола.
![Дијаграм за централизирана верзиска контрола](png/centralized.png)
Ова поставување нуди многу предности, особено во однос на локалните VCS. На пример, сите до одреден степен дознаваат што прават сите други во проектот. Администраторите имаат контрола во вркса со кој што може да го направи, а тоа е далеку полесно да се направи во CVCS отколку да се справи со локалните бази на податоци за секој клиент.
Сепак, ова поставување, исто така, има некои сериозни недостатоци. Најочигледна е единствената точка на неуспех што го претставува централизираниот сервер. Ако тој сервер се спушти за еден час, тогаш за тој час никој воопшто не може да соработува или да ги зачува верзиите на она што тие го работат. Ако хард дискот на кој се наоѓа централната база на податоци станува корумпиран и не се чуваат правилни бекап, вие изгубите апсолутно сè - целата историја на проектот, освен она што се случува на еден поединечен случај на локални машини. Локалните VCS системи страдаат од истиот проблем - секогаш кога ја имате целата историја на проектот на едно место, ризикувате да изгубите сè.
Дистрибуирани системи за верзиска контрола
Тука влегуваат системи за контрола на дистрибуирани верзиски контролни системи(DVCSs). Во DVCS (на пример Git, Mercurial, Bazaar или Darcs), клиентите не само што ја проверуваат најновата слика на датотеките, тие целосно го отсликуваат складиштето, вклучувајќи ја целосната историја. Така, ако било кој сервер не е достапен, и овие системи соработувале преку тој сервер, било кое од клиентските складишта може да се копира назад до серверот за да се врати. Секој клон е целосна копија од сите податоци.
![Дистрибуирани системи за верзиска контролас](png/distributed.png)
Понатаму, многу од овие системи се направени така да може да работат со неколку оддалечени складишта со кои можат да работат, така што можете да соработувате со различни групи на луѓе на различни начини истовремено во рамките на истиот проект. Ова овозможува да поставите неколку типови на работни процеси кои не се можни во централизираните системи, како што се хиерархиски модели.