Първи стъпки с Git: изчерпателно ръководство за начинаещи

Вместо въведение

Здравейте! Днес ще говорим за система за контрол на версиите, а именно Git. Нямате нищо общо с програмирането, ако не знаете/разбирате Git. Но красотата е, че не е нужно да пазите всички команди и функции на Git в главата си, за да бъдете постоянно заети. Трябва да знаете набор от команди, които ще ви помогнат да разберете всичко, което се случва.

Основи на Git

Git е разпределена система за контрол на версиите за нашия code. Защо ни трябва? Разпределените екипи се нуждаят от няHowва система за управление на тяхната работа. Необходимо е да се проследят промените, които настъпват във времето. Тоест трябва да можем да видим стъпка по стъпка кои файлове са се променor и How. Това е особено важно, когато проучвате Howво се е променило в контекста на една задача, което прави възможно отмяната на промените.

Инсталиране на Git

Нека инсталираме Java на вашия компютър.

Инсталиране на Windows

Както обикновено, трябва да изтеглите и стартирате exe файл. Тук всичко е просто: кликнете върху първата връзка в Google , изпълнете инсталацията и това е всичко. За да направим това, ще използваме bash конзолата, предоставена от Windows. В Windows трябва да стартирате Git Bash. Ето How изглежда в менюто "Старт": Сега това е команден ред, с който можете да работите. За да не се налага всеки път да отивате в папката с проекта, за да отворите Git там, можете да отворите командния ред в папката на проекта с десния бутон на мишката с пътя, от който се нуждаем:

Инсталиране на Linux

Обикновено Git е част от Linux дистрибуции и вече е инсталиран, тъй като това е инструмент, който първоначално е написан за разработка на Linux ядро. Но има ситуации, когато не е така. За да проверите, трябва да отворите терминал и да напишете: git --version. Ако получите разбираем отговор, тогава нищо не трябва да се инсталира. Отворете терминал и инсталирайте Git на Ubuntu . Работя върху Ubuntu, така че мога да ви кажа Howво да напишете за него: sudo apt-get install git.

Инсталиране на macOS

Тук също първо трябва да проверите дали Git вече е там. Ако го нямате, тогава най-лесният начин да го получите е да изтеглите най-новата version тук . Ако Xcode е инсталиран, тогава Git определено ще се инсталира автоматично.

Настройки на Git

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

git config --global user.name "Ivan Ivanov"
git config --global user.email ivan.ivanov@gmail.com

Ако трябва да промените автора за конкретен проект, можете да премахнете "--global". Това ще ни даде следното:

git config user.name "Ivan Ivanov"
git config user.email ivan.ivanov@gmail.com

Малко теория...

За да се потопим в темата, трябва да ви запознаем с няколко нови думи и действия...

• git хранorще
• ангажирам
• клон
• сливане
• конфликти
• дръпнете
• тласък
• How да игнорирате някои файлове (.gitignore)

И така нататък.

Статуси в Git

Git има няколко статуи, които трябва да бъдат разбрани и запомнени:

• непроследен
• модифициран
• инсцениран
• ангажирани

Как трябва да разбирате това?

Това са статуси, които се прилагат към файловете, съдържащи нашия code:

1. Файл, който е създаден, но все още не е добавен към хранorщето, има статус „непроследен“.
2. Когато правим промени във файлове, които вече са добавени към хранorщето на Git, тогава техният статус е „променен“.
3. Сред файловете, които сме променor, ние избираме тези, от които се нуждаем, и тези класове се променят в състояние "поетапно".
4. Създава се ангажимент от подготвени файлове в етапно състояние и отива в хранorщето на Git. След това няма файлове със статус "поетапно". Но все още може да има файлове, чийто статус е "променен".

Ето How изглежда:

Какво е ангажимент?

Комитът е основното събитие, когато става дума за контрол на версиите. Той съдържа всички промени, напequalsи от началото на ангажимента. Ангажиментите са свързани заедно като единично свързан списък. По-конкретно: има първи ангажимент. Когато се създаде вторият комит, той знае Howво идва след първия. И по този начин информацията може да бъде проследена. Комитът също има своя собствена информация, така наречените метаданни:

• уникалният идентификатор на комита, който може да се използва за намирането му
• името на автора на комита, който го е създал
• датата, на която е създаден ангажиментът
• коментар, който описва Howво е напequalsо по време на ангажимента

Ето How изглежда:

Какво е клон?

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

Първи стъпки с Git

Можете да работите Howто с локално хранorще, така и с отдалечено. За да практикувате необходимите команди, можете да се ограничите до локалното хранorще. Той само съхранява цялата информация за проекта локално в папката .git. Ако говорим за отдалеченото хранorще, тогава цялата информация се съхранява някъде на отдалечения сървър: само копие на проекта се съхранява локално. Промените, напequalsи във вашето локално копие, могат да бъдат изпратени (git push) към отдалеченото хранorще. В нашата дискусия тук и по-долу говорим за работа с Git в конзолата. Разбира се, можете да използвате няHowво решение, базирано на GUI (например IntelliJ IDEA), но първо трябва да разберете Howви команди се изпълняват и Howво означават.

Работа с Git в локално хранorще

След това ви предлагам да следвате и да изпълните всички стъпки, които направих, докато четехте статията. Това ще подобри вашето разбиране и усвояване на материала. Е, приятен апетит! :) За да създадете локално хранorще, трябва да напишете:

git init

Това ще създаде папка .git в текущата директория на конзолата. Папката .git съхранява цялата информация за Git хранorщето. Не го изтривайте ;) След това файловете се добавят към проекта и им се присвоява статус „Непроследено“. За да проверите текущото състояние на вашата работа, напишете това:

git status

Ние сме в главния клон и ще останем тук, докато не преминем към друг клон. Това показва кои файлове са променени, но все още не са добавени към статуса „поетапно“. За да ги добавите към статуса "staged", трябва да напишете "git add". Тук имаме няколко опции, например:

• git add -A — добавяне на всички файлове към статус „поетапно“.
• git add. — добавете всички файлове от тази папка и всички подпапки. По същество това е същото като предишното
• git add <име на файл> — добавя конкретен файл. Тук можете да използвате регулярни изрази, за да добавяте файлове според няHowъв модел. Например git add *.java: Това означава, че искате да добавяте само файлове с разширение java.

Първите две опции са очевидно прости. Нещата стават по-интересни с най-новото допълнение, така че нека напишем:

git add *.txt

За да проверим състоянието, използваме вече известната ни команда:

git status

Тук можете да видите, че регулярният израз е работил правилно: test_resource.txt вече има статус „поетапно“. И накрая, последният етап за работа с локално хранorще (има още един, когато работите с отдалечено хранorще ;)) — създаване на нов комит:

git commit -m "all txt files were added to the project"

Следва страхотна команда за разглеждане на хронологията на комитите на клон. Нека се възползваме от него:

git log

Тук можете да видите, че създадохме първия си ангажимент и той включва текста, който предоставихме в командния ред. Много е важно да се разбере, че този текст трябва да обяснява възможно най-точно Howво е напequalsо по време на този ангажимент. Това ще ни помогне много пъти в бъдеще. Любознателен читател, който още не е заспал, може би се чуди Howво се е случило с file GitTest.java. Нека разберем веднага. За да направим това, използваме:

git status

Както можете да видите, той все още е „непроследен“ и чака своето време. Но Howво ще стане, ако изобщо не искаме да го добавим към проекта? Понякога това се случва. За да направим нещата по-интересни, нека сега се опитаме да променим нашия файл test_resource.txt. Нека добавим малко текст там и да проверим състоянието:

git status

Тук можете ясно да видите разликата между статусите „непроследен“ и „променен“. GitTest.java е „непроследен“, докато test_resource.txt е „модифициран“. Сега, когато имаме файлове в модифицирано състояние, можем да разгледаме промените, напequalsи в тях. Това може да стане с помощта на следната команда:

git diff

Тоест можете ясно да видите тук Howво добавих към нашия текстов файл: здравей свят! Нека добавим нашите промени към текстовия файл и да създадем ангажимент:

git add test_resource.txt
git commit -m "added hello word! to test_resource.txt"

За да видите всички ангажименти, напишете:

git log

Както можете да видите, сега имаме два ангажимента. Ще добавим GitTest.java по същия начин. Тук няма коментари, само команди:

git add GitTest.java
git commit -m "added GitTest.java"
git status

Работа с .gitignore

Ясно е, че искаме да запазим само изходния code и нищо друго в хранorщето. И така, Howво друго може да има? Като минимум компorрани класове и/or файлове, генерирани от среди за разработка. За да кажем на Git да ги игнорира, трябва да създадем специален файл. Направете следното: създайте файл с име .gitignore в корена на проекта. Всеки ред в този файл представлява модел, който трябва да се игнорира. В този пример файлът .gitignore ще изглежда така:

```
*.class
target/
*.iml
.idea/
```

Нека да разгледаме:

• Първият ред е да игнорирате всички файлове с разширение .class
• Вторият ред е да игнорирате папката "target" и всичко, което съдържа
• Третият ред е да игнорирате всички файлове с разширение .iml
• Четвъртият ред е да игнорирате папката .idea

Нека опитаме с пример. За да видите How работи, нека добавим компorрания GitTest.class към проекта и да проверим състоянието на проекта:

git status

Ясно е, че не искаме по няHowъв начин случайно да добавим компorрания клас към проекта (използвайки git add -A). За да направите това, създайте файл .gitignore и добавете всичко, което беше описано по-рано: Сега нека използваме ангажимент, за да добавим file .gitignore към проекта:

git add .gitignore
git commit -m "added .gitignore file"

И сега моментът на истината: имаме компorран клас GitTest.class, който е "непроследен", който не искахме да добавим към хранorщето на Git. Сега трябва да видим ефектите от file .gitignore:

git status

Перфектно! .gitignore +1 :)

Работа с клонове и други подобни

Естествено, работата само в един клон е неудобна за самотни разработчици и е невъзможна, когато има повече от един човек в екип. Ето защо имаме клонове. Както казах по-рано, клонът е просто подвижен указател към ангажименти. В тази част ще разгледаме работата в различни клонове: How да обединим промените от един клон в друг, Howви конфликти могат да възникнат и много повече. За да видите списък с всички клонове в хранorщето и да разберете в кой се намирате, трябва да напишете:

git branch -a

Можете да видите, че имаме само един главен клон. Звездицата пред него показва, че сме в него. Между другото, можете също да използвате командата "git status", за да разберете в кой клон се намираме. След това има няколко опции за създаване на клонове (може да има повече - това са тези, които използвам):

• създайте нов клон въз основа на този, в който се намираме (99% от случаите)
• създаване на клон въз основа на конкретен ангажимент (1% от случаите)

Нека създадем клон въз основа на конкретен ангажимент

Ще разчитаме на уникалния идентификатор на ангажимента. За да го намерим, пишем:

git log

Подчертах ангажимента с коментара „добавен здравей свят...“ Неговият уникален идентификатор е 6c44e53d06228f888f2f454d3cb8c1c976dd73f8. Искам да създам клон "разработка", който започва от този ангажимент. За да направя това, пиша:

git checkout -b development 6c44e53d06228f888f2f454d3cb8c1c976dd73f8

Създава се клон само с първите два комита от главния клон. За да проверим това, първо се уверяваме, че сме превключor към друг клон и гледаме броя на ангажиментите там:

git status
git log

И Howто се очаква, имаме два ангажимента. Между другото, ето един интересен момент: все още няма .gitignore файл в този клон, така че нашият компorран файл (GitTest.class) вече е маркиран със статус „непроследен“. Сега можем отново да прегледаме нашите клонове, като напишем това:

git branch -a

Можете да видите, че има два клона: "master" и "development". В момента сме в процес на разработка.

Нека създадем клон на базата на текущия

Вторият начин за създаване на клон е да го създадете от друг. Искам да създам клон на базата на главния клон. Първо трябва да премина към него и следващата стъпка е да създам нов. Нека да разгледаме:

• git checkout master — превключване към главния клон
• git status — проверете дали наистина сме в главния клон

Тук можете да видите, че превключихме към главния клон, файлът .gitignore е в сила и компorраният клас вече не е маркиран като „непроследен“. Сега създаваме нов клон на базата на главния клон:

git checkout -b feature/update-txt-files

Ако не сте сигурни дали този клон е същият като "master", можете лесно да проверите, като изпълните "git log" и прегледате всички ангажименти. Трябва да има четири от тях.

Разрешаване на конфликти

Преди да проучим Howво е конфликт, трябва да поговорим за сливането на един клон в друг. Тази картина изобразява процеса на сливане на един клон в друг: Тук имаме основен клон. В даден момент вторичен клон се създава от основния клон и след това се модифицира. След като работата е свършена, трябва да обединим единия клон в другия. Няма да описвам различните характеристики: В тази статия искам само да предам общо разбиране. Ако имате нужда от подробности, можете да ги потърсите сами. В нашия пример ние създадохме разклонението функция/актуализация-txt-файлове. Както е посочено от името на клона, ние актуализираме текста. Сега трябва да създадем нов ангажимент за тази работа:

git add *.txt 
git commit -m "updated txt files"
git log

Сега, ако искаме да обединим клона feature/update-txt-files в master, трябва да отидем до master и да напишем "git merge feature/update-txt-files":

git checkout master
git merge feature/update-txt-files
git log

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

git branch -D feature/update-txt-files

Дотук всичко е ясно, нали? Нека усложним ситуацията: сега да кажем, че трябва да промените txt file отново. Но сега този файл ще бъде променен и в главния клон. С други думи, ще се променя паралелно. Git няма да може да разбере Howво да прави, когато искаме да обединим нашия нов code в главния клон. Да тръгваме! Ще създадем нов клон на базата на master, ще направим промени в text_resource.txt и ще създадем ангажимент за тази работа:

git checkout -b feature/add-header
... we make changes to the file

git add *.txt
git commit -m "added header to txt"

Отидете до основния клон и актуализирайте този текстов файл на същия ред като в клона за функции:

git checkout master
… we updated test_resource.txt

git add test_resource.txt
git commit -m "added master header to txt"

И сега най-интересният момент: трябва да обединим промените от клона за функция/добавяне на заглавка към master. Ние сме в главния клон, така че трябва само да напишем:

git merge feature/add-header

Но резултатът ще бъде конфликт във file test_resource.txt: Тук можем да видим, че Git не може да реши сам How да обедини този code. Той ни казва, че първо трябва да разрешим конфликта и едва след това да извършим ангажимента. ДОБРЕ. Отваряме file с конфликта в текстов редактор и виждаме: За да разберем Howво направи Git тук, трябва да си спомним кои промени сме направor и къде и след това да сравним:

1. Промените, които бяха на този ред в главния клон, се намират между "<<<<<<< HEAD" и "=======".
2. Промените, които бяха в клона за функция/добавяне на заглавка, се намират между "=======" и ">>>>>>> функция/добавяне на заглавка".

Ето How Git ни казва, че не може да разбере How да извърши сливането на това място във file. Разделя този раздел на две части от различните клонове и ни приканва сами да разрешим конфликта на сливането. Достатъчно честно. Решавам смело да премахна всичко, оставяйки само думата "хедър": Да видим статуса на промените. Описанието ще бъде малко по-различно. Вместо „променен“ статус, имаме „необединен“. Може ли да споменем пети статус? Не мисля, че това е необходимо. Да видим:

git status

Можем да се убедим, че това е специален, необичаен случай. Да продължим:

git add *.txt

Може да забележите, че описанието предполага писане само на "git commit". Нека се опитаме да напишем това:

git commit

И точно така го направихме — разрешихме конфликта в конзолата. Разбира се, това може да се направи малко по-лесно в интегрирани среди за разработка. Например в IntelliJ IDEA всичко е настроено толкова добре, че можете да извършвате всички необходими действия направо в него. Но IDE правят много неща „под капака“ и често не разбираме Howво точно се случва там. А когато няма разбиране, могат да възникнат проблеми.

Работа с отдалечени хранorща

Последната стъпка е да разберете още няколко команди, които са необходими за работа с отдалеченото хранorще. Както казах, отдалеченото хранorще е място, където се съхранява хранorщето и от което можете да го клонирате. Какъв вид отдалечени хранorща има? Примери:

• GitHub е най-голямата платформа за съхранение на хранorща и съвместна разработка. Вече го описах в предишни статии.
  Последвайте ме в GitHub . Често показвам работата си там в онези области, които уча за работа.

• GitLab е уеб базиран инструмент за жизнения цикъл на DevOps с отворен code . Това е Git -базирана система за управление на codeови хранorща със собствена wiki, система за проследяване на грешки , CI/CD конвейер и други функции.
  След новината, че Microsoft купи GitHub, някои разработчици дублираха проектите си в GitLab.

• BitBucket е уеб услуга за хостинг на проекти и съвместна разработка, базирана на системите за контрол на версиите Mercurial и Git. По едно време имаше голямо предимство пред GitHub, тъй като предлагаше безплатни частни хранorща. Миналата година GitHub също представи тази възможност за всички безплатно.

• И така нататък…

Когато работите с отдалечено хранorще, първото нещо, което трябва да направите, е да клонирате проекта във вашето локално хранorще. За това експортирах проекта, който направихме локално, и сега всеки може да го клонира за себе си, като напише:

git clone https://github.com/romankh3/git-demo

Вече има пълно локално копие на проекта. За да сте сигурни, че локалното копие на проекта е най-новото, трябва да изтеглите проекта, като напишете:

git pull

В нашия случай нищо в отдалеченото хранorще не се е променило в момента, така че отговорът е: Вече е актуално. Но ако направя няHowви промени в отдалеченото хранorще, локалното се актуализира, след като ги изтеглим. И накрая, последната команда е да прехвърлите данните в отдалеченото хранorще. Когато сме направor нещо локално и искаме да го изпратим до отдалеченото хранorще, първо трябва да създадем нов комит локално. За да демонстрираме това, нека добавим нещо друго към нашия текстов файл: Сега нещо доста обичайно за нас — създаваме ангажимент за тази работа:

git add test_resource.txt
git commit -m "prepared txt for pushing"

Командата за изпращане на това към отдалеченото хранorще е:

git push

Е, това е всичко, което исках да кажа. Благодаря за вниманието. Последвайте ме в GitHub , където публикувам различни готини примерни проекти, свързани с личното ми обучение и работа.

Полезен линк

• Официална Git documentация . Препоръчвам го като ориентир.