1. Подробно ръководство за Git за начинаещи

Днес ще говорим за система за контрол на версиите, а именно Git.

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

Основи на Git

Git е разпределена система за контрол на версиите за нашия code. Защо ни трябва? Екипите се нуждаят от няHowва система за управление на работата си. Необходимо е да се проследят промените, които настъпват във времето.

Тоест, трябва да можем да видим стъпка по стъпка кои файлове са се променor и How. Това е особено важно, когато проучвате Howво се е променило в контекста на една задача, което прави възможно отмяната на промените.

Нека си представим следната ситуация: имаме работещ code, всичко в него е добро, но след това решаваме да подобрим or променим нещо. Нищо страшно, но нашето "подобрение" счупи половината функции на програмата и я направи невъзможна за работа. И сега Howво? Без Git ще трябва да седите и да мислите с часове, опитвайки се да си спомните How всичко е било първоначално. Но с Git ние просто връщаме ангажимента — и това е всичко.

Или Howво ще стане, ако има двама разработчици, които правят свои собствени промени в codeа едновременно? Без Git те копират оригиналните codeови файлове и ги променят отделно. Идва момент, когато и двамата искат да добавят своите промени в главната директория. Какво правите в този случай?

Няма да има такива проблеми, ако използвате Git.

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

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

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

Както обикновено, трябва да изтеглите и стартирате exe файл. Тук всичко е просто: кликнете върху първата връзка в Google , изпълнете инсталацията и това е всичко. За да направим това, ще използваме bash конзолата, предоставена от Windows.

В Windows трябва да стартирате Git Bash. Ето How изглежда в менюто "Старт":

Сега това е команден ред, с който можете да работите.

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

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

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

Отворете терминал и инсталирайте. За Ubuntu трябва да напишете: sudo apt-get install git. И това е всичко: сега можете да използвате Git във всеки терминал.

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

Тук също първо трябва да проверите дали Git вече е там (вижте по-горе, същото като при Linux).

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

Git настройки

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

Настройте потребителско име и парола за всички ваши проекти, като изпълните следните команди:

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

Малко теория

За да се потопим в темата, трябва да ви запознаем с няколко нови думи и действия... Иначе няма да има за Howво да говорим. Разбира се, това е жаргон, който идва при нас от английски, така че ще добавя преводи в скоби.

Какви думи и действия?

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

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

Статуси в Git

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

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

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

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

• Файл, който е създаден, но все още не е добавен към хранorщето, има статус „непроследен“.
• Когато правим промени във файлове, които вече са добавени към хранorщето на Git, тогава техният статус е „променен“.
• Сред файловете, които сме променor, ние избираме тези, от които се нуждаем (например, не се нуждаем от компorрани класове) и тези класове се променят в състояние "поетапно".
• Създава се ангажимент от подготвени файлове в етапно състояние и отива в хран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 в текущата директория на конзолата.

Папката .git съхранява цялата информация за Git хранorщето. Не го изтривай ;)

След това файловете се добавят към проекта и им се присвоява статус „Непроследен“. За да проверите текущото състояние на вашата работа, напишете това:

Ние сме в главния клон и ще останем тук, докато не преминем към друг клон.

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

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

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

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

Тук можете да видите, че регулярният израз е работил правилно: test_resource.txt вече има статус „поетапно“.

И накрая, последният етап за работа с локално хранorще (има още един, когато работите с отдалечено хранorще ;)) — създаване на нов комит:

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

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

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

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

За да направим нещата по-интересни, нека сега се опитаме да променим нашия файл test_resource.txt. Нека добавим малко текст там и да проверим състоянието:

Тук можете ясно да видите разликата между статусите „непроследен“ и „променен“.

GitTest.java е „непроследен“, докато test_resource.txt е „модифициран“.

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

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

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

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

Както можете да видите, сега имаме два ангажимента.

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

Работа с .gitignore

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

За да кажем на Git да ги игнорира, трябва да създадем специален файл. Направете следното: създайте файл с име .gitignore в корена на проекта. Всеки ред в този файл представлява модел, който трябва да се игнорира.

В този пример файлът .gitignore ще изглежда така:

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

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

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

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

Сега нека използваме ангажимент, за да добавим file .gitignore към проекта:

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

Сега трябва да видим ефектите от file .gitignore:

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

Работа с клонове

Естествено, работата само в един клон е неудобна за самотни разработчици и е невъзможна, когато има повече от един човек в екип. Ето защо имаме клонове.

Клонът е просто подвижен указател към ангажименти.

В тази част ще разгледаме работата в различни клонове: How да обединим промените от един клон в друг, Howви конфликти могат да възникнат и много повече.

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

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

След това има няколко опции за създаване на клонове (може да има повече - това са тези, които използвам):

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

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

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

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

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

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

Сега можем отново да прегледаме нашите клонове, като напишем това:

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

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

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

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

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

Сега създаваме нов клон на базата на главния клон:

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

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

Преди да проучим Howво е конфликт, трябва да поговорим за сливането на един клон в друг.

Тази снимка изобразява процеса на сливане на един клон в друг:

Тук имаме основен клон. В даден момент вторичен клон се създава от основния клон и след това се модифицира. След като работата е свършена, трябва да обединим единия клон в другия.

В нашия пример ние създадохме разклонението функция/актуализация-txt-файлове. Както е посочено от името на клона, ние актуализираме текста.

Сега трябва да създадем нов ангажимент за тази работа:

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

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

Тази функционалност беше добавена, така че можете да изтриете клон на функция. За да направим това, ние пишем:

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

Ще създадем нов клон на базата на master, ще направим промени в text_resource.txt и ще създадем ангажимент за тази работа:

... правим промени във file

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

… актуализирахме test_resource.txt

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

Но резултатът ще бъде конфликт във file test_resource.txt:

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

ДОБРЕ. Отваряме file с конфликта в текстов редактор и виждаме:

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

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

Ето How Git ни казва, че не може да разбере How да извърши сливането на това място във file. Разделя този раздел на две части от различните клонове и ни приканва сами да разрешим конфликта на сливането.

Достатъчно честно. Смело решавам да премахна всичко, оставяйки само думата "header":

Нека да разгледаме състоянието на промените. Описанието ще бъде малко по-различно. Вместо „променен“ статус, имаме „необединен“. Може ли да споменем пети статус? Не мисля, че това е необходимо. Да видим:

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

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

И точно така го направихме — разрешихме конфликта в конзолата.

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

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

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

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

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

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

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

За целта експортирахме проекта, който направихме локално. Сега всеки може да го клонира за себе си, като напише:

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

В нашия случай нищо в отдалеченото хранorще не се е променило в момента, така че отговорът е: Вече е актуално.

Но ако направим промени в отдалеченото хранorще, локалното се актуализира, след като ги изтеглим.

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

Сега нещо доста обичайно за нас — създаваме ангажимент за тази работа:

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

Това е за сега!

2. Как да работите с Git в IntelliJ IDEA

В тази част ще научите How да работите с Git в IntelliJ IDEA.

Необходими входове:

1. Прочетете, следвайте и разберете предишната част. Това ще помогне да се гарантира, че всичко е настроено и готово за работа.
2. Инсталирайте IntelliJ IDEA. Тук всичко трябва да е наред :)
3. Отделете един час, за да постигнете пълно майсторство.

Нека работим с демонстрационния проект , който използвах за статията за Git.

Клонирайте проекта локално

Тук има два варианта:

1. Ако вече имате акаунт в GitHub и искате да натиснете нещо по-късно, по-добре е да разклоните проекта и да клонирате собственото си копие. Можете да прочетете How да създадете разклонение в друга статия под заглавието Пример за работния процес на разклонение .
2. Клонирайте хранorщето и правете всичко локално, без да имате възможност да прехвърлите всичко на сървъра.

За да клонирате проект от GitHub, трябва да копирате връзката към проекта и да я прехвърлите на IntelliJ IDEA:

1. Копирайте address на проекта:

2. Отворете IntelliJ IDEA и изберете „Вземете от контрола на версиите“:

3. Копирайте и поставете address на проекта:

4. Ще бъдете подканени да създадете проект IntelliJ IDEA. Приемете офертата:

5. Тъй като няма система за изграждане, избираме „Създаване на проект от съществуващи източници“:

6. След това ще видите този красив екран:

Сега, след като разбрахме клонирането, можете да се огледате.

Първи поглед към IntelliJ IDEA като Git UI

Погледнете по-отблизо клонирания проект: вече можете да получите много информация за системата за контрол на версиите.

Първо, имаме панела за контрол на версиите в долния ляв ъгъл. Тук можете да намерите всички локални промени и да получите списък с ангажименти (аналогично на "git log").

Нека да преминем към обсъждане на Log. Има известна визуализация, която ни помага да разберем How точно е протекло развитието. Например, можете да видите, че е създаден нов клон с добавена заглавка към txt commit, който след това е обединен в главния клон. Ако щракнете върху ангажимент, можете да видите в десния ъгъл цялата информация за ангажимента: всички негови промени и метаданни.

Освен това можете да видите действителните промени. Виждаме също, че там е разрешен конфликт. IDEA също представя това много добре.

Ако щракнете двукратно върху file, който е променен по време на този комит, ще видим How е разрешен конфликтът:

Отбелязваме, че отляво и отдясно имаме двете версии на един и същи файл, които трябваше да бъдат обединени в един. И в средата имаме крайния обединен резултат.

Когато един проект има много клонове, ангажименти и потребители, трябва да търсите отделно по клон, потребител и дата:

Преди да започнете, също си струва да обясните How да разберете в кой бранш се намираме.

В долния десен ъгъл има бутон с надпис „Git: master“. Всичко, което следва "Git:", е текущият клон. Ако щракнете върху бутона, можете да направите много полезни неща: да превключите към друг клон, да създадете нов, да преименувате съществуващ и т.н.

Работа с хранorще

Полезни клавишни комбинации

За бъдеща работа трябва да запомните няколко много полезни клавишни комбинации:

1. CTRL+T — Вземете последните промени от отдалеченото хранorще (git pull).
2. CTRL+K — Създайте ангажимент / вижте всички текущи промени. Това включва Howто непроследени, така и модифицирани файлове (git commit).
3. CTRL+SHIFT+K — Това е командата за натискане на промени в отдалеченото хранorще. Всички ангажименти, създадени локално и все още не в отдалеченото хранorще, ще бъдат насочени (git push).
4. ALT+CTRL+Z — Възстановяване на промените в конкретен файл до състоянието на последния комит, създаден в локалното хранorще. Ако изберете целия проект в горния ляв ъгъл, можете да отмените промените във всички файлове.

Howво искаме

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

Целта е да внедрите нова функционалност в отделен клон и след това да я преместите в отдалечено хранorще (тогава трябва да създадете и заявка за изтегляне към главния клон, но това е извън обхвата на този урок).

Какво е необходимо за това?

1. Вземете всички текущи промени в основния клон (например "master").

2. От този основен клон създайте отделен клон за вашата работа.

3. Внедрете новата функционалност.

4. Отидете до основния клон и проверете дали е имало нови промени, докато работим. Ако не, значи всичко е наред. Но ако има промени, тогава правим следното: отиваме в работния клон и пребазираме промените от основния клон към нашия. Ако всичко върви добре, тогава страхотно. Но е напълно възможно да има конфликти. Както се случва, те просто могат да бъдат решени предварително, без да губите време в отдалеченото хранorще.

   Чудите ли се защо трябва да направите това? Това е добро възпитание и предотвратява възникването на конфликти след натискане на вашия клон към локалното хранorще (има, разбира се, възможност конфликтите да възникнат, но тя става много по-малка ) .

5. Изпратете вашите промени в отдалеченото хранorще.

Как да получа промени от отдалечения сървър?

Добавихме описание към README с нов ангажимент и искаме да получим тези промени. Ако са напequalsи промени Howто в локалното хранorще, така и в отдалеченото, тогава сме поканени да изберем между сливане и повторно базиране. Избираме да се слеем.

Въведете CTRL+T :

Сега можете да видите How се е променил README, т.е. промените от отдалеченото хранorще са изтеглени, а в долния десен ъгъл можете да видите всички подробности за промените, дошли от сървъра.

Създайте нов клон на базата на master

Тук всичко е просто.

Отидете в долния десен ъгъл и щракнете върху Git: master . Изберете + Нов клон .

Оставете отметката в квадратчето Checkout branch и въведете името на новия клон. В нашия случай: това ще бъде readme-improver .

След това Git: master ще се промени на Git: readme-improver .

Нека симулираме паралелна работа

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

Ще редактираме README с нов ангажимент през браузъра, като по този начин симулираме паралелна работа. Сякаш някой е направил промени в същия файл, докато работим върху него. Резултатът ще бъде конфликт. Ще премахнем думата "fully" от ред 10.

Внедрете нашата функционалност

Нашата задача е да променим README и да добавим описание към новата статия. Тоест работата в Git минава през IntelliJ IDEA. Добави Това:

Промените са напequalsи. Сега можем да създадем ангажимент. Натиснете CTRL+K , което ни дава:

Преди да създадем ангажимент, трябва да разгледаме внимателно Howво предлага този прозорец.

В секцията Commit Message пишем текст, свързан с ангажимента. След това, за да го създадем, трябва да щракнете върху Commit .

Пишем, че README е променен и създаваме ангажимента. В долния ляв ъгъл се появява предупреждение с името на ангажимента:

Проверете дали основният клон се е променил

Изпълнихме задачата си. Работи. Писахме тестове. Всичко е наред. Но преди да преминем към сървъра, все пак трябва да проверим дали междувременно е имало промени в главния клон. Как може да стане това? Много лесно: някой получава задача след вас и този някой я изпълнява по-бързо, отколкото вие изпълнявате задачата си.

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

В главния клон натиснете CTRL+T , за да получите последните промени от отдалечения сървър. Гледайки Howви са промените, можете лесно да видите Howво се е случило:

Думата "fully" беше премахната. Може би някой от маркетинга е решил, че не трябва да се пише така и е дал задача на разработчиците да го актуализират.

Вече имаме локално копие на най-новата version на главния клон. Върнете се към readme-improver .

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

Ако сте направor всичко правилно и сте следвали заедно с мен, резултатът трябва да покаже конфликт във file README:

Тук също имаме много информация, която да разберем и попием. Тук е показан списък с файлове (в нашия случай един файл), които имат конфликти. Можем да избираме от три опции:

1. приемете вашето — приемете само промени от readme-improver.
2. приемат техните — приемат само промени от главния.
3. сливане — изберете сами Howво искате да запазите и Howво да изхвърлите.

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

Тук можем да видим, че има три части:

1. Това са промените от readme-improver.
2. Обединеният резултат. Засега е това, което съществуваше преди промените.
3. Промените от главния клон.

Трябва да произведем общ резултат, който да задоволи всички. Преглеждайки Howво е променено ПРЕДИ нашите промени, разбираме, че те просто премахнаха думата "fully". Добре няма проблем! Това означава, че ние също ще го премахнем в обединения резултат и след това ще добавим нашите промени. След като коригираме обединения резултат, можем да щракнете върху Прилагане .

След това ще се появи известие, което ни казва, че повторното базиране е успешно:

Там! Разрешихме първия си конфликт чрез IntelliJ IDEA.

Пуснете промените към отдалечения сървър

Следващата стъпка е да изпратите промените на отдалечения сървър и да създадете заявка за изтегляне. За да направите това, просто натиснете CTRL+SHIFT+K . Тогава получаваме:

Отляво ще има списък с ангажименти, които не са бor прехвърлени към отдалеченото хранorще. Вдясно ще бъдат всички променени файлове. И това е! Натиснете Push и ще изпитате щастие :)

Ако натискането е успешно, ще видите подобно известие в долния десен ъгъл:

Бонус: създаване на заявка за изтегляне

Нека отидем в хранorще на GitHub и ще видим, че GitHub вече знае Howво искаме:

Щракнете върху Сравняване и изтегляне на заявка . След това щракнете върху Създаване на заявка за изтегляне . Тъй като разрешихме конфликтите предварително, сега, когато създаваме заявка за изтегляне, можем веднага да я обединим:

Това е за сега!