С правилните познания всеки може да овладее git. След като започнете да го разбирате, терминологията ще има повече смисъл и вие (в крайна сметка) ще се научите дори и да я харесвате.
Какво е Git?
На първо място нека уточним, че git не е GitHub. Много хора разбираемо бъркат двете понятия. GitHub е уебсайт за хостинг на проекти, които използват git.
Git е тип система за контрол на версиите (version control system или само VCS), която улеснява проследяването на промените във файловете. Например, когато редактирате файл, Git може да ви помогне да определите точно какво се е променило спрямо предишното състояние, кой го е променил и защо – сега може да изглеждат (не)малко безсмислени тези въпроси, но имайте малко търпение и продължете четенето.
Използването на такава система е полезно и за координиране на работата между множество хора работещи по даден проект и също за проследяването на напредъка по проекта във времето чрез запазване на „контролни точки“. Можете да използвате Git например докато пишете есе или за да проследявате промени в дизайн файлове.
Git не е единствената система за контрол на версиите, но със сигурност е най-популярната. Много разработчици на софтуер използват Git ежедневно и разбирането как да го използвате може да даде значителен тласък на автобиографията ви.
Използвате интерфейса на командния ред, като пишете в терминала. Ако не сте запознати с терминалите, това е добре – опитайте тогава първо това (или потърсете помощ в Google).
Git е разпределителна система за контрол на версиите, която е с отворен код.
Това са много думи за една дефиниция. Нека да я разбием на по-лесно смилаеми парчета и да обясним какво е:
- Система за контрол: Това основно означава, че Git е инструмент проследяващ съдържанието. Git може да се използва за съхранение на всякакво съдържание, но той се използва най-вече за съхраняване на програмен код поради другите функционалности, които предоставя.
- Система за управление на версиите: Кодът, който се съхранява в Git се съхранява с промените извършени по него по време на добавянето на повече код. Също така разработчиците могат да добавят код паралелно. Така че системата за контрол на версиите помага при това, като поддържа история на случилите се промени. Също така Git предоставя функции като бранчове (клонове) и обединения, които ще разгледаме по-късно.
- Разпределителна система за контрол на версиите : Git може да има отдалечено хранилище, което се съхранява на сървър и локално хранилище, което се съхранява в компютъра на всеки разработчик. Това означава, че кодът не се съхранява само на едно място в някакъв централен сървър, а пълното копие на съдържанието присъства на всички компютри на разработчиците. Git е разпределителна система за контрол на версиите, тъй като кодът присъства на компютъра на всеки разработчик. Ще обясним концепцията за отдалечени и локални хранилища по-късно в тази статия, но преди това…
Защо ни е необходима система за контрол на версиите като Git
Софтуерните проекти в реалния живот обикновено се изпълняват от множество разработчици, които работят паралелно по тях. Поради тази причина е необходима система за контрол на версиите като Git, за да се гарантира, че между разработчиците няма да има конфликти на кода, който пишат.
Освен това изискванията в такива проекти често се променят. Така че системата за контрол на версиите позволява на разработчиците да се връщат и към по-стари версии на вече написаният код.
И накрая, понякога няколко проекта, които се изпълняват паралелно, включват една и съща база с код. В такъв случай концепцията за разклоняване (branching) в Git е с много голяма важност.
Да започнем с това как да използваме Git
Вместо да споменем всички понятия наведнъж, ще обясним основните понятия в Git чрез примери, така че да е по-лесно да се следват. Примерите по-долу предполагат, че използвате CLI.
Първо изтеглете Git
Тази връзка съдържа подробности за това как да инсталирате Git в множеството операционни системи:
https://git-scm.com/book/en/v2/Getting-Started-Installing-Git . Много е възможно да имате вече инсталиран Git, така че проверете дали Git е инсталиран, като използвате следната команда в командния ред:
git —version
Създаване на локално хранилище в Git
Във вашия компютър създайте нова празна папка, която ще съдържа вашия проект. Нека именуваме папката на проекта simple-git-demo.
Отидете във вашата папка и добавете локално хранилище на Git към проекта, като използвате следните команди:
cd simple-git-demo
git init
С git init командата добавяме Git хранилището на проекта.
Стартирайте със собствено хранилище от нулата (във всяка съществуваща папка на вашия компютър).
Това ще създаде скрита папка .git във вашата текуща папка – това ще е „хранилището“ (или репото / repository – repo), където git съхранява всички свои вътрешни данни за проследяване. Всички промени, които правите във всички файлове в оригиналната папка, вече ще могат да се проследяват.
✨ Оригиналната папка сега е вашата работна директория, за разлика от хранилището (папката .git), която ще проследява вашите промени. Работите само в работната директория. Просто е! Сега да видим как…
Да добавим малко код
Създайте файл, наречен demo.txt в папката на проекта, и добавете следния текст в него:
Initial Content
Тук ще демонстрираме работа с Git само с обикновен текст вместо с действителен код, тъй като основният фокус на тази статия е върху Git, а не върху някакъв специфичен език за програмиране. А и така ще опростим значително нещата.
Staging и Committing на кода
Commit се нарича процесът, при който кодът се добавя към локалното хранилище – в пряк превод това означава “предаване за съхранение”. Преди да добавите кода там обаче, той трябва да бъде поставен в зоната наречена staging – това е междинно място при което се прави копие на файловете от работната директория преди да се добавят към локалното хранилище. Тази област следи за всички файлове, които трябва да бъдат добавени към хранилището.
Всеки файл, който не е добавен там, няма да бъде сложен/изпратен в хранилището. Това дава на разработчика контрол върху това кои файлове трябва да бъдат committed в Git.
Staging
git add <files>
След като редактирате някои файлове, тази команда ще маркира всички промени, които сте направили, като ”staged” (или „готови за изпращане в хранилището“). Този процес в същността си представялава копиране на файловете в място наречено stage.
⚠️ Ако след това отидете и направите още промени в някои от файловете, тези нови промени няма да бъдат автоматично добавени в тази зона, дори ако сте променили същите файлове от преди това. Това е много полезно за контролиране на точно това, което искате да изпратите в хранилището, но също така и е основен източник на объркване за новодошлите при git.
Използвайте следната команда за да копирате файла от нашият пример в staging зоната:
git add demo.txt
😎 В случай, че искате да копирате (добавите) няколко файла наведнъж, можете да използвате заместващите символи – wildcards (както е и при всяка друга команда в терминал). Например:
git add file1.txt file2.txt file3.txt
Ако искате да добавите всички файлове в папката на проекта, използвайте следната команда:
git add .
Използвайте това внимателно, тъй като това добавя всички файлове и папки във вашия проект към зоната предшестваща добавянето в хранилището. Същата команда може да се изпише и така:
git add –all
Ако някога се породят съмнения относно какво се случва в даденият момент в git, просто въведете git status за да разберете (повече за това по-долу). Тази команда ще изведе „Промени, които трябва да бъдат извършени:“, последвано от имена на файлове в зелено. След това ще видите „Промени, които не са организирани за изпращане:“, последвано от имената на файлове в червено. Те все още не са организирани.
Committing
Използвайте следната команда, за да добавите промените си в Git:
git commit
Това ще отвори редактора на текст в командния ред, който е по подразбиране и ще ви “помоли” да въведете пояснително/уточняващо съобщение относно промените във файловете ви. Веднага щом запаметите и излезете, вашият commit ще бъде запазен/записан на локалният git.
Съобщението за commit е важно, за да помогнете на другите хора (и на самите вас в даден момент) да разберат какво е променено и защо сте го променили. Тук ще намерите и кратко ръководство, обясняващо как да пишете полезни съобщения при commit.
😎 Знайте, че можете да използвате флага -m като пряк път за въвеждане на съобщение.
git commit -m „Initial Commit“
„Initial Commit” (Първоначален къмит) е съобщението. В нашият пример въведете съответното съобщение, за да посочите какви промени в кода са направени в този конкретен момент.
😎 Повечето от командите в git имат допълнителни параметри, които можете да им предадете, за да ги персонализирате (и за краткост), които правят всичко по-интересно (разбирайте: объркващо). Обикновено има повече от един начин за изпълнение на дадена задача.
Git Status и Git Log
Сега модифицирайте demo.txt файла и добавете следния фрагмент:
Initial Content Adding more Content
Статус (състояние)
Използвайте git status за да откриете информация относно това какви файлове са модифицирани и какви файлове има в зоната за инсцениране – показва и друга информация, която засега можем да игнорираме. Използвайте следната команда, за да видите състоянието:
git status
Състоянието показва, че demo.txt е модифициран и все още не е в зоната за постановка.
Сега нека добавим demo.txt към подреждащата област и я ангажираме, като използваме следните команди:
git add demo.txt git commit -m „demo.txt file is modified“
Log
Използвайте git log за отпечатване на всички commits, които са направени досега.
Командата, използвана за това, е:
git log
Дневникът показва автора на всеки commit, датата на която е commit-нат и съобщението добавено по време на commit-а.
Branch-ове / клонове
Досега не сме създали нито един branch (клон) в Git. По подразбиране Git комитите влизат в главния branch.
Какво е branch?
Branch-ът не е нищо друго освен указател към най-новият комит в хранилището на Git. Така че в момента нашият главен branch е указател към вторият комит “demo.txt file is modified”.
Защо са ни необходими множество branch-ове?
Необходими са множество branch-ове, за да може да се поддържат множество разработки паралелно. Вижте изображението по-долу, за да видите как работят branch-овете.
Първоначално Commit 1 и Commit 2 бяха създадени в главния branch. След Commit 2 се създава нов branch, наречен “Test”, и Commit 3 и Commiit 4 са добавени към него.
В същото време към главния branch се добавят различни Commit 3 и Commit 4. Тук можем да видим, че след Commit 2 вече се правят две паралелни разработки в 2 отделни branch-а.
Тестовият branch и главният branch се разминават тук и имат различен код – кодът от тестовия клон може да бъде обединен с главния клон с помощта на командата git merge. Това ще бъде разгледано по-късно.
Създайте нов branch в Local
git branch <new-branch-name>
Можете да мислите за това като за създаване на локален „контролен пункт“ (технически се нареча референция) и да зададете собствено име. Подобно е като при създаването на файл в текстов редактор – File > Save as…; новият branch, който се създава, е препратка към текущото състояние на вашето репо. След това името на branch-а може да се използва в различни други команди, както съвсем скоро и ще видите.
Подобно на разклоняване, по-често ще запазвате всяка контролна точка, докато вървите под формата на комити (вижте git commit).
Commit-ите са определен тип контролна точка, наречена ревизия. Името ще бъде произволно създаден хеш от цифри и букви – нещо като: e093542. След това този хеш може да се използва в различни други команди, точно като имената на branch-овете.
✨ Това всъщност е основната функция на git: Да запазва контролни точки (ревизии) и да ги споделя с други хора. Всичко се върти около тази концепция.
Ако някога сте създавали контролна точка към нещо в git, винаги ще можете да се върнете към нея по-късно, стига вашата папка .git да е непокътната. Това е вълшебството на Git. Вижте git reflog, ако се интересувате да научите повече.
Branch концепцията е огромна и сложна тема. Можете да прочетете повече тук – https://git-scm.com/book/en/v2/Git-Branching-Branches-in-a-Nutshell.
Създайте нов branch, наречен test, като използвате следната команда:
git branch test
Тази команда създава branch именуван test.
Все още сме в контекста на главния branch. За да преминете към test използвайте следната команда:
git checkout test
Сега вече сме в test branch-а.
Можете да мислите за това като за „възобновяване“ от съществуващ контролен пункт. Всички ваши файлове ще бъдат възстановени до състоянието, в което са били в конкретния branch.
Имайте предвид, че всички промени във вашата работна директория ще бъдат запазени. Вижте git stash, ако се интересувате от лесен начин да избегнете малко главоболие.
😎 Можете да използвате флага -b като пряк път за създаване на нов branch и след това да се пехвърлите на него – всичко в една стъпка. Това е доста често използвано:
git checkout -b test
Можете да видите всички branch-ове в репото, което се намира локално на вашата машина, като използвате следната команда:
git branch
Вижте разликите между контролните точки:
git diff <branch-name> <other-branch-name>
След като редактирате някои файлове, можете просто да напишете git diff, за да видите списък с направените промени. Това е добър начин да проверите отново работата си, преди да я запишете в репото си.
За всяка група промени ще видите как е изглеждал файлът (с префикс – и оцветен в червено), последван от това как изглежда сега (с префикс + и оцветен в зелено).
Направете някои commits в новия branch
Променете, demo.txt като добавите следния фрагмент:
Initial Content Adding more Content Adding some Content from test Branch
Сега поетапно добавете към sataging зоната и изпълнете commit като използвате следните команди заедно:
git add demo.txt git commit -m „Test Branch Commit“
Този commit беше направен в тестовия branch и сега тестовият branch изпреварва главния branch с 1 commit – това е така, понеже тестовият branch включва и 2 commits от главния branch.
Можете да проверите историята на commits в Test Branch, като използвате следната команда:
git log
Merging / Сливане
В момента Test Branch изпреварва Master с 1 commit. Да кажем, че сега искаме целият код в Test Branch да бъде “върнат” обратно в Master Branch. Тук е мястото да използваме git merge.
За да обедините (слеете) кода от тестовия branch в главния branch, изпълнете следните стъпки:
Първо се върнете към главния branch:
git checkout master
След това изпълнете командата merge:
git merge test
След изпълнението на тези 2 команди обединяването трябва да бъде успешно. В този пример няма да имаме конфликти, но в реалните проекти обикновено има когато се извършва обединяване. Разрешаването на конфликта е нещо, което идва с опита, така че като работите повече с Git, ще можете да вземете решения и за разрешаването на конфликти.
Стартирайте git log сега и ще забележите, че master вече също има 3 commits.