1. En detaljerad guide till Git för nybörjare

Idag ska vi prata om ett versionskontrollsystem, nämligen Git.

Du kan verkligen inte vara en fullfjädrad programmerare utan att känna till och förstå detta verktyg. Naturligtvis behöver du inte ha alla Git-kommandon och funktioner i huvudet för att vara kontinuerligt anställd. Du behöver känna till en uppsättning kommandon som hjälper dig att förstå allt som händer.

Grunderna i Git

Git är ett distribuerat versionskontrollsystem för vår kod. Varför behöver vi det? Team behöver något slags system för att hantera sitt arbete. Det behövs för att spåra förändringar som sker över tid.

Det vill säga att vi måste kunna se steg för steg vilka filer som har ändrats och hur. Detta är särskilt viktigt när du undersöker vad som har förändrats i samband med en enskild uppgift, vilket gör det möjligt att återställa ändringarna.

Låt oss föreställa oss följande situation: vi har fungerande kod, allt i den är bra, men sedan bestämmer vi oss för att förbättra eller justera något. Ingen stor sak, men vår "förbättring" bröt hälften av programmets funktioner och gjorde det omöjligt att fungera. Så vad nu? Utan Git skulle du behöva sitta och tänka i timmar och försöka komma ihåg hur allt var från början. Men med Git drar vi bara tillbaka commit - och det är allt.

Eller vad händer om det finns två utvecklare som gör sina egna kodändringar samtidigt? Utan Git kopierar de originalkodfilerna och modifierar dem separat. Det kommer en tid då båda vill lägga till sina ändringar i huvudkatalogen. Vad gör du i det här fallet?

Det blir inga sådana problem om du använder Git.

Installerar Git

Låt oss installera Java på din dator. Denna process skiljer sig något för olika operativsystem.

Installerar på Windows

Som vanligt måste du ladda ner och köra en exe-fil. Allt är enkelt här: klicka på den första Google-länken , utför installationen och det är allt. För att göra detta kommer vi att använda bash-konsolen som tillhandahålls av Windows.

På Windows måste du köra Git Bash. Så här ser det ut i startmenyn:

Nu är det här en kommandotolk som du kan arbeta med.

För att undvika att behöva gå till mappen med projektet varje gång för att beställa att öppna Git där, kan du öppna kommandotolken i projektmappen med höger musknapp med sökvägen vi behöver:

Installerar på Linux

Vanligtvis är Git en del av Linux-distributioner och är redan installerat, eftersom det är ett verktyg som ursprungligen skrevs för Linux-kärnutveckling. Men det finns situationer när det inte är det. För att kontrollera måste du öppna en terminal och skriva: git --version. Om du får ett begripligt svar behöver ingenting installeras.

Öppna en terminal och installera. För Ubuntu måste du skriva: sudo apt-get install git. Och det är det: nu kan du använda Git i vilken terminal som helst.

Installerar på macOS

Även här måste du först kontrollera om Git redan finns där (se ovan, samma som på Linux).

Om du inte har det är det enklaste sättet att få det att ladda ner den senaste versionen . Om Xcode är installerat kommer Git definitivt att installeras automatiskt.

Git-inställningar

Git har användarinställningar för användaren som ska skicka in arbete. Detta är vettigt och är nödvändigt, eftersom Git tar denna information för fältet Author när en commit skapas.

Ställ in ett användarnamn och lösenord för alla dina projekt genom att köra följande kommandon:

Om du behöver ändra författaren för ett specifikt projekt (för ett personligt projekt, till exempel), kan du ta bort "--global". Detta kommer att ge oss följande:

Lite teori

För att dyka in i ämnet bör vi introducera dig för några nya ord och handlingar... Annars blir det inget att prata om. Naturligtvis är detta jargong som kommer till oss från engelska, så jag lägger till översättningar inom parentes.

Vilka ord och handlingar?

• git repository
• begå
• gren
• sammanfoga
• konflikter
• dra
• skjuta på
• hur man ignorerar vissa filer (.gitignore)

Och så vidare.

Status i Git

Git har flera statyer som måste förstås och komma ihåg:

• ospårad
• ändrad
• iscensatt
• engagerad

Hur ska du förstå detta?

Dessa är statusar som gäller för filerna som innehåller vår kod. Med andra ord, deras livscykel ser vanligtvis ut så här:

• En fil som har skapats men ännu inte lagts till i förvaret har statusen "ospårad".
• När vi gör ändringar i filer som redan har lagts till i Git-förvaret, är deras status "modifierad".
• Bland filerna som vi har ändrat väljer vi de som vi behöver (till exempel behöver vi inte kompilerade klasser), och dessa klasser ändras till statusen "stadium".
• En commit skapas från förberedda filer i stegvis tillstånd och går in i Git-förvaret. Efter det finns det inga filer med statusen "iscenesatt". Men det kan fortfarande finnas filer vars status är "modifierad".

Så här ser det ut:

Vad är ett åtagande?

En commit är huvudhändelsen när det kommer till versionskontroll. Den innehåller alla ändringar som gjorts sedan commit började. Commits är länkade ihop som en enkellänkad lista.

Specifikt finns det ett första åtagande. När den andra commit skapas vet den (den andra) vad som kommer efter den första. Och på detta sätt kan information spåras.

En commit har också sin egen information, så kallad metadata:

• commits unika identifierare, som kan användas för att hitta den
• namnet på uppdragets författare, som skapade det
• det datum då åtagandet skapades
• en kommentar som beskriver vad som gjordes under commit

Så här ser det ut:

Vad är en gren?

En gren är en pekare till någon commit. Eftersom en commit vet vilken commit som föregår den, när en gren pekar på en commit, gäller alla de tidigare commits också för den.

Följaktligen kan vi säga att du kan ha så många grenar du vill som pekar på samma commit.

Arbete sker i grenar, så när en ny commit skapas, flyttar grenen sin pekare till den senaste commit.

Komma igång med Git

Du kan arbeta med ett lokalt arkiv ensamt såväl som med ett fjärranslutet.

För att öva de nödvändiga kommandona kan du begränsa dig till det lokala förrådet. Den lagrar bara all information om projektet lokalt i .git-mappen.

Om vi ​​pratar om fjärrförvaret, så lagras all information någonstans på fjärrservern: endast en kopia av projektet lagras lokalt. Ändringar som görs i din lokala kopia kan skickas (git push) till fjärrförvaret.

I vår diskussion här och nedan pratar vi om att arbeta med Git i konsolen. Naturligtvis kan du använda någon form av GUI-baserad lösning (till exempel IntelliJ IDEA), men först bör du ta reda på vilka kommandon som körs och vad de betyder.

Arbeta med Git i ett lokalt arkiv

För att skapa ett lokalt arkiv måste du skriva:

Detta kommer att skapa en dold .git-mapp i konsolens nuvarande katalog.

.git-mappen lagrar all information om Git-förvaret. Ta inte bort det ;)

Därefter läggs filer till i projektet och de tilldelas statusen "Ospårade". För att kontrollera aktuell status för ditt arbete, skriv detta:

Vi är i mastergrenen, och här kommer vi att vara kvar tills vi byter till en annan gren.

Detta visar vilka filer som har ändrats men som ännu inte har lagts till i "scensatt" status. För att lägga till dem till "stadium"-statusen måste du skriva "git add". Vi har några alternativ här, till exempel:

• git add -A — lägg till alla filer till statusen "stadium".
• git add . — lägg till alla filer från den här mappen och alla undermappar. I huvudsak samma som den föregående;
• git add <file name> — lägger till en specifik fil. Här kan du använda reguljära uttryck för att lägga till filer enligt något mönster. Till exempel, git add *.java: Detta betyder att du bara vill lägga till filer med java-tillägget.

De två första alternativen är helt klart enkla. Saker och ting blir mer intressanta med det senaste tillskottet, så låt oss skriva:

För att kontrollera status använder vi kommandot som vi redan känner till:

Här kan du se att det reguljära uttrycket har fungerat korrekt: test_resource.txt har nu statusen "stadium".

Och slutligen, det sista steget för att arbeta med ett lokalt arkiv (det finns ett till när du arbetar med fjärrarkivet ;)) — skapa en ny commit:

Nästa upp är ett bra kommando för att titta på commit-historiken på en gren. Låt oss använda det:

Här kan du se att vi har skapat vår första commit och den innehåller texten som vi angav på kommandoraden. Det är mycket viktigt att förstå att den här texten så noggrant som möjligt ska förklara vad som gjordes under denna överenskommelse. Detta kommer att hjälpa oss många gånger i framtiden.

En nyfiken läsare som ännu inte har somnat kanske undrar vad som hände med filen GitTest.java. Låt oss ta reda på det nu. För att göra detta använder vi:

Som ni ser är den fortfarande "ospårad" och väntar i kulisserna. Men tänk om vi inte alls vill lägga till det i projektet? Ibland händer det.

För att göra saker mer intressanta, låt oss nu försöka ändra vår test_resource.txt-fil. Låt oss lägga till lite text där och kontrollera statusen:

Här kan du tydligt se skillnaden mellan "ospårad" och "modifierad" status.

GitTest.java är "untracked", medan test_resource.txt är "modifierad".

Nu när vi har filer i det modifierade tillståndet kan vi granska ändringarna som gjorts i dem. Detta kan göras med följande kommando:

Det vill säga du kan tydligt se här vad jag lagt till i vår textfil: hej värld!

Låt oss lägga till våra ändringar i textfilen och skapa en commit:

För att titta på alla åtaganden, skriv:

Som du kan se har vi nu två commits.

Vi lägger till GitTest.java på samma sätt. Inga kommentarer här, bara kommandon:

Arbetar med .gitignore

Det är klart att vi bara vill behålla källkoden ensam, och inget annat, i förvaret. Så vad mer kan det finnas? Åtminstone kompilerade klasser och/eller filer genererade av utvecklingsmiljöer.

För att säga åt Git att ignorera dem måste vi skapa en speciell fil. Gör så här: skapa en fil som heter .gitignore i projektets rot. Varje rad i den här filen representerar ett mönster att ignorera.

I det här exemplet kommer .gitignore-filen att se ut så här:

Låt oss ta en titt:

• Den första raden är att ignorera alla filer med tillägget .class
• Den andra raden är att ignorera mappen "mål" och allt den innehåller
• Den tredje raden är att ignorera alla filer med tillägget .iml
• Den fjärde raden är att ignorera mappen .idea

Låt oss försöka använda ett exempel. För att se hur det fungerar, låt oss lägga till den kompilerade GitTest.class till projektet och kontrollera projektets status:

Uppenbarligen vill vi inte på något sätt av misstag lägga till den kompilerade klassen till projektet (med git add -A). För att göra detta, skapa en .gitignore-fil och lägg till allt som beskrevs tidigare:

Låt oss nu använda en commit för att lägga till .gitignore-filen till projektet:

Och nu sanningens ögonblick: vi har en kompilerad klass GitTest.class som är "untracked", som vi inte ville lägga till i Git-förvaret.

Nu bör vi se effekterna av .gitignore-filen:

Perfekt! .gitignore +1 :)

Arbeta med grenar

Naturligtvis är det obekvämt att arbeta i bara en gren för ensamma utvecklare, och det är omöjligt när det finns mer än en person i ett team. Det är därför vi har filialer.

En gren är bara en rörlig pekare till commits.

I den här delen kommer vi att utforska att arbeta i olika grenar: hur man slår ihop förändringar från en gren till en annan, vilka konflikter som kan uppstå och mycket mer.

För att se en lista över alla grenar i förvaret och förstå vilken du befinner dig i måste du skriva:

Du kan se att vi bara har en mastergren. Asterisken framför den indikerar att vi är i den. Du kan förresten även använda kommandot "git status" för att ta reda på vilken gren vi befinner oss i.

Sedan finns det flera alternativ för att skapa grenar (det kan finnas fler — det här är de jag använder):

• skapa en ny filial baserat på den vi är i (99% av fallen)
• skapa en filial baserat på ett specifikt åtagande (1 % av fallen)

Låt oss skapa en gren baserat på en specifik commit

Vi förlitar oss på commitens unika identifierare. För att hitta den skriver vi:

Vi har markerat commit med kommentaren "added hello world..." Dess unika identifierare är 6c44e53d06228f888f2f454d3cb8c1c976dd73f8. Vi vill skapa en "utvecklings"-gren som utgår från detta åtagande. För att göra detta skriver vi:

En gren skapas med endast de två första commits från mastergrenen. För att verifiera detta ser vi först till att byta till en annan filial och tittar på antalet commits där:

Och som väntat har vi två åtaganden. Förresten, här är en intressant poäng: det finns ingen .gitignore-fil i den här grenen ännu, så vår kompilerade fil (GitTest.class) är nu markerad med statusen "ospårad".

Nu kan vi granska våra filialer igen genom att skriva detta:

Du kan se att det finns två grenar: "master" och "development". Vi är för närvarande under utveckling.

Låt oss skapa en gren baserat på den nuvarande

Det andra sättet att skapa en gren är att skapa den från en annan. Vi vill skapa en gren baserad på mastergrenen. Först måste vi byta till det, och nästa steg är att skapa en ny. Låt oss ta en titt:

• git checkout master — växla till mastergrenen
• git status — verifiera att vi faktiskt är i mastergrenen

Här kan du se att vi bytte till mastergrenen, .gitignore-filen är aktiv och den kompilerade klassen är inte längre markerad som "ospårad".

Nu skapar vi en ny gren baserad på mastergrenen:

Om du är osäker på om denna gren är samma som "master" kan du enkelt kontrollera genom att köra "git log" och titta på alla commits. Det borde vara fyra av dem.

Konfliktlösning

Innan vi utforskar vad en konflikt är måste vi prata om att slå samman en gren till en annan.

Den här bilden skildrar processen att slå samman en gren till en annan:

Här har vi en huvudgren. Vid något tillfälle skapas en sekundär gren från huvudgrenen och modifieras sedan. När arbetet är klart måste vi slå samman den ena grenen i den andra.

I vårt exempel skapade vi grenen feature/update-txt-files. Som framgår av filialens namn uppdaterar vi texten.

Nu måste vi skapa en ny commit för detta arbete:

Om vi ​​nu vill slå samman grenen feature/update-txt-files till master, måste vi gå till master och skriva "git merge feature/update-txt-files":

Som ett resultat inkluderar mastergrenen nu även commit som lades till feature/update-txt-filer.

Den här funktionen lades till så att du kan ta bort en funktionsgren. För att göra detta skriver vi:

Låt oss komplicera situationen: låt oss nu säga att du måste ändra txt-filen igen. Men nu kommer den här filen att ändras i mastergrenen också. Det kommer med andra ord att förändras parallellt. Git kommer inte att kunna ta reda på vad vi ska göra när vi vill slå samman vår nya kod till mastergrenen.

Vi skapar en ny gren baserad på master, gör ändringar i text_resource.txt och skapar en commit för detta arbete:

... vi gör ändringar i filen

Gå till huvudgrenen och uppdatera även denna textfil på samma rad som i funktionsgrenen:

… vi uppdaterade test_resource.txt

Och nu den mest intressanta punkten: vi måste slå samman ändringar från grenen feature/add-header till master. Vi är i mastergrenen, så vi behöver bara skriva:

Men resultatet blir en konflikt i filen test_resource.txt:

Här kan vi se att Git inte kunde bestämma på egen hand hur den här koden skulle slås samman. Det talar om för oss att vi måste lösa konflikten först och först sedan utföra åtagandet.

OK. Vi öppnar filen med konflikten i en textredigerare och ser:

För att förstå vad Git gjorde här måste vi komma ihåg vilka ändringar vi gjorde och var, och sedan jämföra:

1. Ändringarna som fanns på den här raden i mastergrenen finns mellan "<<<<<<< HEAD" och "========".
2. Ändringarna som fanns i grenen feature/add-header finns mellan "=======" och ">>>>>>> feature/add-header”.

Så här berättar Git för oss att den inte kunde ta reda på hur man utför sammanslagningen på den här platsen i filen. Den delade upp detta avsnitt i två delar från de olika grenarna och uppmanar oss att själva lösa sammanslagningskonflikten.

Rimligt nog. Jag bestämmer mig djärvt för att ta bort allt och lämnar bara ordet "header":

Låt oss titta på status för ändringarna. Beskrivningen kommer att vara något annorlunda. Istället för en "modifierad" status har vi "unmerged". Så kunde vi ha nämnt en femte status? Jag tror inte att detta är nödvändigt. Låt oss se:

Vi kan övertyga oss själva om att detta är ett speciellt, ovanligt fall. Låt oss fortsätta:

Du kanske märker att beskrivningen föreslår att du bara skriver "git commit". Låt oss försöka skriva det:

Och precis som det gjorde vi det — vi löste konflikten i konsolen.

Naturligtvis kan detta göras lite lättare i integrerade utvecklingsmiljöer. Till exempel, i IntelliJ IDEA, är allt så väl inställt att du kan utföra alla nödvändiga åtgärder direkt inom det. Men IDE:er gör många saker "under huven", och vi förstår ofta inte exakt vad som händer där. Och när det inte finns någon förståelse kan problem uppstå.

Arbeta med fjärrlager

Det sista steget är att ta reda på några fler kommandon som behövs för att fungera med fjärrförvaret.

Som jag sa, ett fjärrlager är någon plats där förvaret lagras och från vilket du kan klona det.

Vilken typ av fjärrlager finns det? Exempel:

• GitHub är den största lagringsplattformen för repositories och samarbetsutveckling.
• GitLab är ett webbaserat verktyg för DevOps livscykel med öppen källkod. Det är ett Git-baserat system för att hantera kodlager med sin egen wiki, buggspårningssystem, CI/CD-pipeline och andra funktioner.
• BitBucket är en webbtjänst för projekthosting och samarbetsutveckling baserad på Mercurial och Git versionskontrollsystem. En gång hade den en stor fördel gentemot GitHub genom att den erbjöd gratis privata arkiv. Förra året introducerade GitHub också denna möjlighet för alla gratis.
• Och så vidare…

När du arbetar med ett fjärrarkiv är det första du ska göra att klona projektet till ditt lokala arkiv.

För detta exporterade vi projektet som vi gjorde lokalt Nu kan alla klona det för sig själva genom att skriva:

Det finns nu en komplett lokal kopia av projektet. För att vara säker på att den lokala kopian av projektet är den senaste måste du dra projektet genom att skriva:

I vårt fall har ingenting i fjärrförvaret förändrats för närvarande, så svaret är: Redan uppdaterad.

Men om vi gör några ändringar i fjärrlagret uppdateras det lokala efter att vi hämtat dem.

Och slutligen är det sista kommandot att skicka data till fjärrförvaret. När vi har gjort något lokalt och vill skicka det till fjärrförvaret måste vi först skapa en ny commit lokalt. För att demonstrera detta, låt oss lägga till något annat till vår textfil:

Nu är något ganska vanligt för oss - vi skapar ett åtagande för detta arbete:

Kommandot för att skicka detta till fjärrförvaret är:

Det var allt för nu!

2. Hur man arbetar med Git i IntelliJ IDEA

I den här delen kommer du att lära dig hur du arbetar med Git i IntelliJ IDEA.

Nödvändiga ingångar:

1. Läs, följ med och förstå föregående del. Detta kommer att hjälpa till att säkerställa att allt är inställt och redo att gå.
2. Installera IntelliJ IDEA. Allt ska vara i sin ordning här :)
3. Tilldela en timme för att uppnå fullständig behärskning.

Låt oss arbeta med demoprojektet som jag använde för artikeln om Git.

Klona projektet lokalt

Det finns två alternativ här:

1. Om du redan har ett GitHub-konto och vill pusha något senare, är det bättre att dela projektet och klona din egen kopia. Du kan läsa om hur du skapar en gaffel i en annan artikel under rubriken Ett exempel på arbetsflödet för forking .
2. Klona förvaret och gör allt lokalt utan möjlighet att skicka det hela till servern.

För att klona ett projekt från GitHub måste du kopiera projektlänken och skicka den till IntelliJ IDEA:

1. Kopiera projektets adress:

2. Öppna IntelliJ IDEA och välj "Hämta från versionskontroll":

3. Kopiera och klistra in projektadressen:

4. Du kommer att bli ombedd att skapa ett IntelliJ IDEA-projekt. Acceptera erbjudandet:

5. Eftersom det inte finns något byggsystem väljer vi "Skapa projekt från befintliga källor":

6. Nästa kommer du att se denna vackra skärm:

Nu när vi kom på kloning kan du ta en titt.

Första anblicken på IntelliJ IDEA som ett Git-gränssnitt

Ta en närmare titt på det klonade projektet: du kan redan få mycket information om versionskontrollsystemet.

Först har vi versionskontrollfönstret i det nedre vänstra hörnet. Här kan du hitta alla lokala ändringar och få en lista över commits (analogt med "git log").

Låt oss gå vidare till en diskussion om Log. Det finns en viss visualisering som hjälper oss att förstå exakt hur utvecklingen har gått till. Till exempel kan du se att en ny gren skapades med en tillagd rubrik till txt commit, som sedan slogs samman till huvudgrenen. Om du klickar på en commit kan du se i det högra hörnet all information om commit: alla dess ändringar och metadata.

Dessutom kan du se de faktiska förändringarna. Vi ser också att en konflikt löstes där. IDEA presenterar också detta mycket väl.

Om du dubbelklickar på filen som ändrades under denna commit kommer vi att se hur konflikten löstes:

Vi noterar att till vänster och höger har vi de två versionerna av samma fil som behövde slås samman till en. Och i mitten har vi det slutliga sammanslagna resultatet.

När ett projekt har många grenar, commits och användare måste du söka separat efter gren, användare och datum:

Innan man sätter igång är det också värt att förklara hur man förstår vilken gren vi befinner oss i.

I det nedre högra hörnet finns en knapp märkt "Git: master". Vad som än följer efter "Git:" är den nuvarande grenen. Om du klickar på knappen kan du göra många användbara saker: byta till en annan gren, skapa en ny, byta namn på en befintlig och så vidare.

Arbeta med ett förråd

Användbara snabbtangenter

För framtida arbete måste du komma ihåg några mycket användbara snabbtangenter:

1. CTRL+T — Hämta de senaste ändringarna från fjärrförvaret (git pull).
2. CTRL+K — Skapa en commit/se alla aktuella ändringar. Detta inkluderar både ospårade och modifierade filer (git commit).
3. CTRL+SHIFT+K — Det här är kommandot för att skicka ändringar till fjärrförvaret. Alla commits som skapats lokalt och ännu inte finns i fjärrlagret kommer att pushas (git push).
4. ALT+CTRL+Z — Återställ ändringar i en specifik fil till tillståndet för den senaste commit som skapades i det lokala arkivet. Om du väljer hela projektet i det övre vänstra hörnet kan du återställa ändringar i alla filer.

Vad vill vi ha?

För att få jobbet gjort behöver vi bemästra ett grundscenario som används överallt.

Målet är att implementera ny funktionalitet i en separat gren och sedan skjuta den till ett fjärrlager (då måste du också skapa en pull-förfrågan till huvudgrenen, men det ligger utanför den här lektionens omfattning).

Vad krävs för att göra detta?

1. Få alla aktuella ändringar i huvudgrenen (till exempel "master").

2. Från denna huvudgren skapar du en separat gren för ditt arbete.

3. Implementera den nya funktionen.

4. Gå till huvudgrenen och kontrollera om det har skett några nya ändringar medan vi arbetade. Om inte, så är allt bra. Men om det fanns förändringar gör vi följande: gå till arbetsgrenen och basera om ändringarna från huvudgrenen till vår. Om allt går bra, så bra. Men det är fullt möjligt att det blir konflikter. Som det händer kan de bara lösas i förväg, utan att slösa tid i fjärrförvaret.

   Undrar du varför du ska göra detta? Det är gott uppförande och förhindrar att konflikter uppstår efter att du har skjutit din filial till det lokala förvaret (det finns naturligtvis en möjlighet att konflikter fortfarande kommer att uppstå, men den blir mycket mindre).

5. Skicka dina ändringar till fjärrförvaret.

Hur får man ändringar från fjärrservern?

Vi har lagt till en beskrivning till README med en ny commit och vill få dessa ändringar. Om ändringar gjordes både i det lokala arkivet och i det avlägsna, så uppmanas vi att välja mellan en sammanslagning och en rebas. Vi väljer att slå samman.

Skriv CTRL+T :

Du kan nu se hur README har förändrats, dvs ändringarna från fjärrförvaret drogs in, och i det nedre högra hörnet kan du se alla detaljer om ändringarna som kom från servern.

Skapa en ny gren baserad på master

Allt är enkelt här.

Gå till det nedre högra hörnet och klicka på Git: master . Välj + Ny gren .

Lämna kryssrutan Checkout filial markerad och ange namnet på den nya filialen. I vårt fall: detta kommer att vara readme-förbättrare .

Git: master kommer då att ändras till Git: readme-improver .

Låt oss simulera parallellt arbete

För att konflikter ska uppstå måste någon skapa dem.

Vi kommer att redigera README med en ny commit genom webbläsaren, vilket simulerar parallellt arbete. Det är som om någon gjorde ändringar i samma fil medan vi arbetade med den. Resultatet blir en konflikt. Vi kommer att ta bort ordet "fully" från rad 10.

Implementera vår funktionalitet

Vår uppgift är att ändra README och lägga till en beskrivning till den nya artikeln. Det vill säga arbetet i Git går genom IntelliJ IDEA. Lägg till detta:

Ändringarna är gjorda. Nu kan vi skapa en commit. Tryck på CTRL+K , vilket ger oss:

Innan vi skapar en commit måste vi ta en närmare titt på vad det här fönstret erbjuder.

I avsnittet Commit Message skriver vi text som är kopplad till commit. Sedan för att skapa den måste vi klicka på Commit .

Vi skriver att README har ändrats och skapar commit. En varning dyker upp i det nedre vänstra hörnet med namnet på commit:

Kontrollera om huvudgrenen har ändrats

Vi slutförde vår uppgift. Det fungerar. Vi skrev prov. Allt är bra. Men innan vi trycker till servern måste vi fortfarande kontrollera om det skett några ändringar i huvudgrenen under tiden. Hur kunde det hända? Ganska enkelt: någon får en uppgift efter dig, och att någon avslutar den snabbare än du slutför din uppgift.

Så vi måste gå till mastergrenen. För att göra detta måste vi göra det som visas i det nedre högra hörnet i skärmdumpen nedan:

I huvudgrenen trycker du på CTRL+T för att hämta de senaste ändringarna från fjärrservern. Om du tittar på vad som har förändrats kan du enkelt se vad som hände:

Ordet "fully" togs bort. Kanske har någon från marknadsföring bestämt att det inte ska skrivas så och gav utvecklarna i uppdrag att uppdatera det.

Vi har nu en lokal kopia av den senaste versionen av masterfilialen. Gå tillbaka till readme-improver .

Nu måste vi lägga om förändringarna från mastergrenen till vår. Vi gör så här:

Om du gjorde allt korrekt och följde med mig, bör resultatet visa en konflikt i README-filen:

Här har vi också mycket information att förstå och insupa. Här visas en lista över filer (i vårt fall en fil) som har konflikter. Vi kan välja mellan tre alternativ:

1. acceptera din — acceptera endast ändringar från readme-improver.
2. acceptera deras — acceptera endast ändringar från master.
3. slå samman — välj själv vad du vill behålla och vad du vill kassera.

Det är inte klart vad som ändrades. Om det finns förändringar i mastergrenen måste de behövas där, så vi kan inte bara acceptera våra förändringar. Följaktligen väljer vi sammanfoga :

Här kan vi se att det finns tre delar:

1. Det här är ändringarna från readme-improver.
2. Det sammanslagna resultatet. För närvarande är det vad som fanns före förändringarna.
3. Ändringarna från mastergrenen.

Vi måste få fram ett sammanslaget resultat som kommer att tillfredsställa alla. När vi granskar vad som ändrades INNAN våra ändringar inser vi att de helt enkelt tog bort ordet "fully". Okej, inga problem! Det betyder att vi också kommer att ta bort det i det sammanslagna resultatet och sedan lägga till våra ändringar. När vi har korrigerat det sammanslagna resultatet kan vi klicka på Använd .

Sedan dyker ett meddelande upp som talar om för oss att rebasen lyckades:

Där! Vi löste vår första konflikt genom IntelliJ IDEA.

Push ändringar till fjärrservern

Nästa steg är att skicka ändringarna till fjärrservern och skapa en pull-begäran. För att göra detta, tryck helt enkelt på CTRL+SHIFT+K . Då får vi:

Till vänster kommer det att finnas en lista över commits som inte har skickats till fjärrarkivet. Till höger kommer alla filer som har ändrats. Och det är allt! Tryck på Push så upplever du lycka :)

Om pushen lyckas kommer du att se ett meddelande så här i det nedre högra hörnet:

Bonus: skapa en pull-begäran

Låt oss gå till ett GitHub-förråd och vi ser att GitHub redan vet vad vi vill ha:

Klicka på Jämför & dra begäran . Klicka sedan på Skapa pull request . Eftersom vi löste konflikterna i förväg kan vi nu när vi skapar en pull-begäran omedelbart slå samman den:

Det var allt för nu!