1. En detaljeret guide til Git for begyndere

I dag skal vi tale om et versionskontrolsystem, nemlig Git.

Du kan virkelig ikke være en fuldgyldig programmør uden at kende og forstå dette værktøj. Selvfølgelig behøver du ikke at have alle Git-kommandoer og funktioner i dit hoved for at være kontinuerligt ansat. Du skal kende et sæt kommandoer, der hjælper dig med at forstå alt, hvad der sker.

Grundlæggende om Git

Git er et distribueret versionskontrolsystem til vores kode. Hvorfor har vi brug for det? Teams har brug for en form for system til at styre deres arbejde. Det er nødvendigt at spore ændringer, der opstår over tid.

Det vil sige, at vi skal kunne se trin-for-trin, hvilke filer der er ændret og hvordan. Dette er især vigtigt, når du undersøger, hvad der ændrede sig i forbindelse med en enkelt opgave, hvilket gør det muligt at fortryde ændringerne.

Lad os forestille os følgende situation: vi har fungerende kode, alt i den er godt, men så beslutter vi os for at forbedre eller justere noget. No big deal, men vores "forbedring" brød halvdelen af ​​programmets funktioner og gjorde det umuligt at arbejde. Så hvad nu? Uden Git ville du skulle sidde og tænke i timevis og prøve at huske, hvordan alting oprindeligt var. Men med Git ruller vi bare commit tilbage - og det er det.

Eller hvad hvis der er to udviklere, der laver deres egne kodeændringer på samme tid? Uden Git kopierer de de originale kodefiler og ændrer dem separat. Der kommer et tidspunkt, hvor begge ønsker at tilføje deres ændringer til hovedbiblioteket. Hvad gør du i dette tilfælde?

Der vil ikke være sådanne problemer, hvis du bruger Git.

Installation af Git

Lad os installere Java på din computer. Denne proces adskiller sig lidt for forskellige operativsystemer.

Installation på Windows

Som sædvanlig skal du downloade og køre en exe-fil. Alt er enkelt her: Klik på det første Google-link , udfør installationen, og det er det. For at gøre dette bruger vi bash-konsollen leveret af Windows.

På Windows skal du køre Git Bash. Sådan ser det ud i startmenuen:

Nu er dette en kommandoprompt, du kan arbejde med.

For at undgå at skulle gå til mappen med projektet hver gang for at bestille at åbne Git der, kan du åbne kommandoprompten i projektmappen med højre museknap med den sti, vi skal bruge:

Installation på Linux

Normalt er Git en del af Linux-distributioner og er allerede installeret, da det er et værktøj, der oprindeligt blev skrevet til Linux-kerneudvikling. Men der er situationer, hvor det ikke er det. For at tjekke, skal du åbne en terminal og skrive: git --version. Hvis du får et forståeligt svar, skal der ikke installeres noget.

Åbn en terminal og installer. For Ubuntu skal du skrive: sudo apt-get install git. Og det er det: nu kan du bruge Git i enhver terminal.

Installerer på macOS

Også her skal du først tjekke, om Git allerede er der (se ovenfor, det samme som på Linux).

Hvis du ikke har det, så er den nemmeste måde at få det på at downloade den nyeste version . Hvis Xcode er installeret, så vil Git helt sikkert blive installeret automatisk.

Git indstillinger

Git har brugerindstillinger for den bruger, der vil indsende arbejde. Dette giver mening og er nødvendigt, fordi Git tager denne information til feltet Author, når en commit oprettes.

Konfigurer et brugernavn og en adgangskode til alle dine projekter ved at køre følgende kommandoer:

Hvis du har brug for at ændre forfatteren til et specifikt projekt (for et personligt projekt, for eksempel), kan du fjerne "--global". Dette vil give os følgende:

Lidt teori

For at dykke ned i emnet bør vi introducere dig til et par nye ord og handlinger... Ellers er der ikke noget at tale om. Selvfølgelig er dette jargon, der kommer til os fra engelsk, så jeg tilføjer oversættelser i parentes.

Hvilke ord og handlinger?

• git repository
• begå
• afdeling
• fusionere
• konflikter
• trække
• skubbe
• hvordan man ignorerer nogle filer (.gitignore)

Og så videre.

Status i Git

Git har flere statuer, der skal forstås og huskes:

• usporet
• modificeret
• iscenesat
• engageret

Hvordan skal du forstå dette?

Dette er statusser, der gælder for de filer, der indeholder vores kode. Med andre ord ser deres livscyklus normalt sådan ud:

• En fil, der er oprettet, men endnu ikke tilføjet til depotet, har statussen "usporet".
• Når vi foretager ændringer i filer, der allerede er blevet tilføjet til Git-lageret, så er deres status "modificeret".
• Blandt de filer, som vi har ændret, vælger vi dem, vi har brug for (for eksempel har vi ikke brug for kompilerede klasser), og disse klasser ændres til "iscenesat" status.
• En commit oprettes fra forberedte filer i trinvis tilstand og går ind i Git-lageret. Derefter er der ingen filer med status "iscenesat". Men der kan stadig være filer, hvis status er "ændret".

Sådan ser det ud:

Hvad er en forpligtelse?

En commit er hovedbegivenheden, når det kommer til versionskontrol. Den indeholder alle de ændringer, der er foretaget siden forpligtelsen begyndte. Commits er knyttet sammen som en enkelt linket liste.

Konkret er der en første commit. Når den anden commit er oprettet, ved den (den anden) hvad der kommer efter den første. Og på denne måde kan information spores.

En commit har også sin egen information, såkaldte metadata:

• forpligtelsens unikke identifikator, som kan bruges til at finde den
• navnet på forpligtelsens forfatter, som oprettede den
• datoen, hvor forpligtelsen blev oprettet
• en kommentar, der beskriver, hvad der blev gjort under commit

Sådan ser det ud:

Hvad er en filial?

En gren er en pegepind til en eller anden forpligtelse. Fordi en commit ved hvilken commit der går forud for den, når en gren peger på en commit, gælder alle de tidligere commits også for den.

Derfor kan vi sige, at du kan have så mange filialer, som du vil, der peger på den samme commit.

Arbejdet foregår i brancher, så når en ny commit oprettes, flytter grenen sin markør til den nyere commit.

Kom godt i gang med Git

Du kan arbejde med et lokalt lager alene såvel som med et fjerntliggende.

For at øve de nødvendige kommandoer kan du begrænse dig til det lokale lager. Den gemmer kun alle projektets oplysninger lokalt i .git-mappen.

Hvis vi taler om fjernlageret, så er al information gemt et sted på fjernserveren: kun en kopi af projektet gemmes lokalt. Ændringer i din lokale kopi kan skubbes (git push) til fjernlageret.

I vores diskussion her og nedenfor taler vi om at arbejde med Git i konsollen. Selvfølgelig kan du bruge en slags GUI-baseret løsning (for eksempel IntelliJ IDEA), men først bør du finde ud af, hvilke kommandoer der udføres, og hvad de betyder.

Arbejder med Git i et lokalt lager

For at oprette et lokalt lager skal du skrive:

Dette vil oprette en skjult .git-mappe i konsollens nuværende mappe.

.git-mappen gemmer al information om Git-lageret. Slet det ikke ;)

Derefter føjes filer til projektet, og de tildeles statussen "Usporet". For at kontrollere den aktuelle status for dit arbejde, skriv dette:

Vi er i mestergrenen, og her bliver vi, indtil vi skifter til en anden gren.

Dette viser, hvilke filer der er ændret, men endnu ikke er blevet tilføjet til "iscenesat" status. For at tilføje dem til "iscenesat" status, skal du skrive "git add". Vi har et par muligheder her, for eksempel:

• git add -A — tilføj alle filer til "iscenesat" status
• git tilføje. — tilføj alle filer fra denne mappe og alle undermapper. I det væsentlige den samme som den forrige;
• git add <file name> — tilføjer en specifik fil. Her kan du bruge regulære udtryk til at tilføje filer efter et eller andet mønster. For eksempel, git add *.java: Det betyder, at du kun ønsker at tilføje filer med java-udvidelsen.

De to første muligheder er klart enkle. Tingene bliver mere interessante med den seneste tilføjelse, så lad os skrive:

For at kontrollere status bruger vi den kommando, vi allerede kender:

Her kan du se, at det regulære udtryk har fungeret korrekt: test_resource.txt har nu status "iscenesat".

Og til sidst, det sidste trin for at arbejde med et lokalt lager (der er et mere, når du arbejder med fjernlageret ;)) — oprettelse af en ny commit:

Dernæst er en fantastisk kommando til at se på forpligtelseshistorien på en filial. Lad os gøre brug af det:

Her kan du se, at vi har oprettet vores første commit, og det inkluderer teksten, som vi leverede på kommandolinjen. Det er meget vigtigt at forstå, at denne tekst skal forklare så præcist som muligt, hvad der blev gjort under denne forpligtelse. Dette vil hjælpe os mange gange i fremtiden.

En nysgerrig læser, der endnu ikke er faldet i søvn, kan undre sig over, hvad der skete med GitTest.java-filen. Lad os finde ud af det lige nu. For at gøre dette bruger vi:

Som du kan se, er den stadig "usporet" og venter i kulissen. Men hvad nu hvis vi slet ikke vil tilføje det til projektet? Nogle gange sker det.

For at gøre tingene mere interessante, lad os nu prøve at ændre vores test_resource.txt-fil. Lad os tilføje noget tekst der og tjekke status:

Her kan du tydeligt se forskellen mellem "usporet" og "modificeret" status.

GitTest.java er "usporet", mens test_resource.txt er "modificeret".

Nu hvor vi har filer i den ændrede tilstand, kan vi undersøge ændringerne i dem. Dette kan gøres ved hjælp af følgende kommando:

Det vil sige, du kan tydeligt se her, hvad jeg tilføjede til vores tekstfil: hej verden!

Lad os tilføje vores ændringer til tekstfilen og oprette en commit:

For at se på alle commits, skriv:

Som du kan se, har vi nu to commits.

Vi tilføjer GitTest.java på samme måde. Ingen kommentarer her, kun kommandoer:

Arbejder med .gitignore

Det er klart, at vi kun ønsker at beholde kildekoden alene, og intet andet, i depotet. Så hvad kunne der ellers være? Som minimum kompilerede klasser og/eller filer genereret af udviklingsmiljøer.

For at fortælle Git at ignorere dem, skal vi oprette en speciel fil. Gør dette: opret en fil kaldet .gitignore i roden af ​​projektet. Hver linje i denne fil repræsenterer et mønster, der skal ignoreres.

I dette eksempel vil .gitignore-filen se sådan ud:

Lad os se:

• Den første linje er at ignorere alle filer med filtypenavnet .class
• Den anden linje er at ignorere mappen "mål" og alt, hvad den indeholder
• Den tredje linje er at ignorere alle filer med filtypenavnet .iml
• Den fjerde linje er at ignorere mappen .idea

Lad os prøve at bruge et eksempel. For at se, hvordan det virker, lad os tilføje den kompilerede GitTest.class til projektet og kontrollere projektets status:

Det er klart, at vi ikke på en eller anden måde ved et uheld vil tilføje den kompilerede klasse til projektet (ved hjælp af git add -A). For at gøre dette skal du oprette en .gitignore-fil og tilføje alt, hvad der blev beskrevet tidligere:

Lad os nu bruge en commit til at tilføje .gitignore-filen til projektet:

Og nu sandhedens øjeblik: vi har en kompileret klasse GitTest.class, der er "usporet", som vi ikke ønskede at tilføje til Git-lageret.

Nu skulle vi se virkningerne af .gitignore-filen:

Perfekt! .gitignore +1 :)

Arbejde med grene

Naturligvis er det ubelejligt at arbejde i én filial for ensomme udviklere, og det er umuligt, når der er mere end én person på et team. Derfor har vi afdelinger.

En gren er blot en bevægelig pegepind til commits.

I denne del vil vi udforske arbejdet i forskellige brancher: hvordan man kan flette ændringer fra en gren til en anden, hvilke konflikter der kan opstå og meget mere.

For at se en liste over alle grene i depotet og forstå, hvilken du er i, skal du skrive:

Du kan se, at vi kun har én mastergren. Stjernen foran indikerer, at vi er i den. Du kan i øvrigt også bruge kommandoen "git status" til at finde ud af, hvilken gren vi er i.

Så er der flere muligheder for at oprette grene (der kan være flere - det er dem, jeg bruger):

• oprette en ny filial baseret på den vi er i (99% af tilfældene)
• oprette en filial baseret på en specifik commit (1 % af tilfældene)

Lad os oprette en filial baseret på en bestemt commit

Vi vil stole på forpligtelsens unikke identifikator. For at finde den skriver vi:

Vi har fremhævet commit med kommentaren "added hello world..." Dens unikke identifikator er 6c44e53d06228f888f2f454d3cb8c1c976dd73f8. Vi ønsker at skabe en "udviklings"-gren, der starter fra denne commit. For at gøre dette skriver vi:

Der oprettes en filial med kun de to første commits fra mastergrenen. For at bekræfte dette skal vi først sørge for at skifte til en anden filial og se på antallet af commits der:

Og som forventet har vi to commits. Forresten, her er en interessant pointe: der er ingen .gitignore-fil i denne gren endnu, så vores kompilerede fil (GitTest.class) er nu fremhævet med "usporet" status.

Nu kan vi gennemgå vores afdelinger igen ved at skrive dette:

Du kan se, at der er to grene: "master" og "udvikling". Vi er i øjeblikket i udvikling.

Lad os oprette en filial baseret på den nuværende

Den anden måde at skabe en gren på er at skabe den fra en anden. Vi ønsker at skabe en filial baseret på mastergrenen. Først skal vi skifte til det, og næste skridt er at oprette en ny. Lad os se:

• git checkout master — skift til mastergrenen
• git status — bekræft, at vi faktisk er i master-grenen

Her kan du se, at vi skiftede til mastergrenen, .gitignore-filen er i kraft, og den kompilerede klasse er ikke længere fremhævet som "usporet".

Nu opretter vi en ny filial baseret på mastergrenen:

Hvis du er usikker på, om denne gren er det samme som "master", kan du nemt tjekke ved at udføre "git log" og se på alle commits. Der skulle være fire af dem.

Konfliktløsning

Før vi udforsker, hvad en konflikt er, skal vi tale om at flette en gren ind i en anden.

Dette billede viser processen med at flette en gren ind i en anden:

Her har vi en hovedgren. På et tidspunkt oprettes en sekundær gren ud fra hovedgrenen og ændres derefter. Når arbejdet er færdigt, skal vi flette den ene gren ind i den anden.

I vores eksempel oprettede vi grenen feature/update-txt-files. Som det fremgår af filialens navn, opdaterer vi teksten.

Nu skal vi oprette en ny commit for dette arbejde:

Hvis vi nu ønsker at flette grenen feature/update-txt-files til master, skal vi gå til master og skrive "git merge feature/update-txt-filer":

Som et resultat inkluderer mastergrenen nu også den commit, der blev tilføjet til feature/update-txt-filer.

Denne funktionalitet blev tilføjet, så du kan slette en funktionsgren. For at gøre dette skriver vi:

Lad os komplicere situationen: lad os nu sige, at du skal ændre txt-filen igen. Men nu vil denne fil også blive ændret i mastergrenen. Det vil med andre ord ændre sig parallelt. Git vil ikke være i stand til at finde ud af, hvad vi skal gøre, når vi vil flette vores nye kode ind i mastergrenen.

Vi opretter en ny filial baseret på master, foretager ændringer til text_resource.txt og opretter en commit til dette arbejde:

... vi foretager ændringer i filen

Gå til mastergrenen og opdater også denne tekstfil på samme linje som i featuregrenen:

… vi opdaterede test_resource.txt

Og nu det mest interessante punkt: vi skal flette ændringer fra feature/add-header-grenen til master. Vi er i mastergrenen, så vi behøver kun at skrive:

Men resultatet vil være en konflikt i filen test_resource.txt:

Her kan vi se, at Git ikke selv kunne bestemme, hvordan denne kode skulle flettes. Det fortæller os, at vi først skal løse konflikten og først derefter udføre forpligtelsen.

OKAY. Vi åbner filen med konflikten i en teksteditor og ser:

For at forstå, hvad Git gjorde her, skal vi huske, hvilke ændringer vi lavede og hvor, og derefter sammenligne:

1. Ændringerne, der var på denne linje i mastergrenen, findes mellem "<<<<<<< HEAD" og "========".
2. Ændringerne der var i feature/add-header grenen findes mellem "=======" og ">>>>>>> feature/add-header”.

Det er sådan, Git fortæller os, at den ikke kunne finde ud af, hvordan man udfører fletningen på denne placering i filen. Den delte dette afsnit i to dele fra de forskellige grene og inviterer os til selv at løse fusionskonflikten.

Fair nok. Jeg beslutter mig dristigt for at fjerne alt og efterlader kun ordet "header":

Lad os se på status for ændringerne. Beskrivelsen vil være lidt anderledes. I stedet for en "modificeret" status har vi "unfusion". Så kunne vi have nævnt en femte status? Jeg tror ikke, det er nødvendigt. Lad os se:

Vi kan overbevise os selv om, at dette er et særligt, usædvanligt tilfælde. Lad os fortsætte:

Du bemærker måske, at beskrivelsen foreslår kun at skrive "git commit". Lad os prøve at skrive det:

Og bare sådan gjorde vi det - vi løste konflikten i konsollen.

Dette kan selvfølgelig gøres lidt lettere i integrerede udviklingsmiljøer. For eksempel i IntelliJ IDEA er alt sat så godt op, at du kan udføre alle de nødvendige handlinger lige i det. Men IDE'er gør mange ting "under motorhjelmen", og vi forstår ofte ikke, hvad der præcist sker der. Og når der ikke er forståelse, kan der opstå problemer.

Arbejde med fjerndepoter

Det sidste trin er at finde ud af et par flere kommandoer, der er nødvendige for at arbejde med fjernlageret.

Som sagt er et fjernlager et sted, hvor depotet er gemt, og hvorfra du kan klone det.

Hvilken slags fjerndepoter er der? Eksempler:

• GitHub er den største lagerplatform for repositories og kollaborativ udvikling.
• GitLab er et webbaseret værktøj til DevOps-livscyklussen med open source. Det er et Git-baseret system til styring af kodelagre med sin egen wiki, fejlsporingssystem, CI/CD-pipeline og andre funktioner.
• BitBucket er en webservice til projekthosting og samarbejdsudvikling baseret på Mercurial og Git versionskontrolsystemerne. På et tidspunkt havde det en stor fordel i forhold til GitHub, idet det tilbød gratis private repositories. Sidste år introducerede GitHub også denne funktion til alle gratis.
• Og så videre…

Når du arbejder med et fjernlager, er den første ting at gøre at klone projektet til dit lokale lager.

Til dette eksporterede vi projektet, som vi lavede lokalt. Nu kan alle klone det for sig selv ved at skrive:

Der er nu en komplet lokal kopi af projektet. For at være sikker på, at den lokale kopi af projektet er den nyeste, skal du trække projektet ved at skrive:

I vores tilfælde er intet i fjernlageret ændret på nuværende tidspunkt, så svaret er: Allerede opdateret.

Men hvis vi foretager ændringer i fjernlageret, opdateres det lokale, efter at vi trækker dem.

Og endelig er den sidste kommando at skubbe dataene til fjernlageret. Når vi har gjort noget lokalt og vil sende det til fjernlageret, skal vi først oprette en ny commit lokalt. For at demonstrere dette, lad os tilføje noget andet til vores tekstfil:

Nu er noget helt almindeligt for os - vi skaber en forpligtelse til dette arbejde:

Kommandoen til at skubbe dette til fjernlageret er:

Det var det for nu!

2. Sådan arbejder du med Git i IntelliJ IDEA

I denne del lærer du, hvordan du arbejder med Git i IntelliJ IDEA.

Nødvendige input:

1. Læs, følg med og forstå den foregående del. Dette vil hjælpe med at sikre, at alt er sat op og klar til at gå.
2. Installer IntelliJ IDEA. Alt skal være i orden her :)
3. Tildel en time for at opnå fuldstændig beherskelse.

Lad os arbejde med demoprojektet , som jeg brugte til artiklen om Git.

Klon projektet lokalt

Der er to muligheder her:

1. Hvis du allerede har en GitHub-konto og vil skubbe noget senere, er det bedre at forgrene projektet og klone din egen kopi. Du kan læse om, hvordan du opretter en gaffel i en anden artikel under overskriften Et eksempel på arbejdsgangen for gaffel .
2. Klon depotet og gør alt lokalt uden mulighed for at skubbe det hele til serveren.

For at klone et projekt fra GitHub skal du kopiere projektlinket og videregive det til IntelliJ IDEA:

1. Kopiér projektets adresse:

2. Åbn IntelliJ IDEA og vælg "Get from Version Control":

3. Kopiér og indsæt projektadressen:

4. Du vil blive bedt om at oprette et IntelliJ IDEA-projekt. Accepter tilbuddet:

5. Da der ikke er noget byggesystem, vælger vi "Opret projekt fra eksisterende kilder":

6. Dernæst vil du se denne smukke skærm:

Nu hvor vi fandt ud af kloning, kan du se dig omkring.

Første blik på IntelliJ IDEA som en Git UI

Se nærmere på det klonede projekt: Du kan allerede få en masse information om versionskontrolsystemet.

For det første har vi versionskontrolruden i nederste venstre hjørne. Her kan du finde alle lokale ændringer og få en liste over commits (analogt med "git log").

Lad os gå videre til en diskussion af Log. Der er en vis visualisering, der hjælper os til at forstå præcis, hvordan udviklingen er forløbet. For eksempel kan du se, at en ny gren blev oprettet med en tilføjet header til txt commit, som derefter blev flettet ind i mastergrenen. Hvis du klikker på en commit, kan du i højre hjørne se al information om commit: alle dens ændringer og metadata.

Desuden kan du se de faktiske ændringer. Vi ser også, at der blev løst en konflikt. IDEA præsenterer også dette meget godt.

Hvis du dobbeltklikker på filen, der blev ændret under denne commit, vil vi se, hvordan konflikten blev løst:

Vi bemærker, at til venstre og højre har vi de to versioner af den samme fil, der skulle flettes sammen til en. Og i midten har vi det endelige sammenlagte resultat.

Når et projekt har mange filialer, commits og brugere, skal du søge separat efter filial, bruger og dato:

Inden man går i gang, er det også værd at forklare, hvordan man forstår, hvilken branche vi er i.

I nederste højre hjørne er der en knap mærket "Git: master". Uanset hvad der følger efter "Git:" er den nuværende gren. Hvis du klikker på knappen, kan du gøre en masse nyttige ting: skifte til en anden gren, oprette en ny, omdøbe en eksisterende, og så videre.

Arbejder med et depot

Nyttige genvejstaster

Til fremtidigt arbejde skal du huske et par meget nyttige genvejstaster:

1. CTRL+T — Hent de seneste ændringer fra fjernlageret (git pull).
2. CTRL+K — Opret en commit/se alle de aktuelle ændringer. Dette inkluderer både usporede og ændrede filer (git commit).
3. CTRL+SHIFT+K — Dette er kommandoen til at skubbe ændringer til fjernlageret. Alle commits, der er oprettet lokalt og endnu ikke er i fjernlageret, vil blive pushet (git push).
4. ALT+CTRL+Z — Rollback ændringer i en specifik fil til tilstanden for den sidste commit oprettet i det lokale lager. Hvis du vælger hele projektet i øverste venstre hjørne, kan du rulle ændringer tilbage i alle filer.

Hvad vil vi?

For at få arbejdet udført, skal vi mestre et grundlæggende scenarie, der bruges overalt.

Målet er at implementere ny funktionalitet i en separat gren og derefter skubbe den til et fjernlager (så skal du også oprette en pull-anmodning til hovedgrenen, men det er uden for denne lektion).

Hvad kræves der for at gøre dette?

1. Få alle de aktuelle ændringer i hovedgrenen (for eksempel "master").

2. Fra denne hovedgren skal du oprette en separat gren til dit arbejde.

3. Implementer den nye funktionalitet.

4. Gå til hovedafdelingen og tjek, om der er sket nye ændringer, mens vi arbejdede. Hvis ikke, så er alt fint. Men hvis der var ændringer, så gør vi følgende: Gå til arbejdsgrenen og rebaser ændringerne fra hovedgrenen til vores. Hvis alt går godt, så fantastisk. Men det er meget muligt, at der kommer konflikter. Som det sker, kan de bare løses på forhånd uden at spilde tid i fjernlageret.

   Undrer du dig over, hvorfor du skal gøre dette? Det er gode manerer og forhindrer konflikter i at opstå efter at have skubbet din filial til det lokale depot (der er selvfølgelig en mulighed for, at der stadig vil opstå konflikter, men den bliver meget mindre ).

5. Skub dine ændringer til fjernlageret.

Hvordan får man ændringer fra fjernserveren?

Vi har tilføjet en beskrivelse til README med en ny commit og ønsker at få disse ændringer. Hvis der blev foretaget ændringer både i det lokale lager og i det fjerne, så opfordres vi til at vælge mellem en fletning og en rebase. Vi vælger at slå sammen.

Indtast CTRL+T :

Du kan nu se, hvordan README har ændret sig, dvs. ændringerne fra fjernlageret blev trukket ind, og i nederste højre hjørne kan du se alle detaljerne om de ændringer, der kom fra serveren.

Opret en ny filial baseret på master

Alt er enkelt her.

Gå til nederste højre hjørne og klik på Git: master . Vælg + Ny filial .

Lad afkrydsningsfeltet Checkout filial være markeret, og indtast navnet på den nye filial. I vores tilfælde: dette vil være readme-forbedrer .

Git: master vil derefter skifte til Git: readme-improver .

Lad os simulere parallelt arbejde

For at konflikter skal opstå, er nogen nødt til at skabe dem.

Vi vil redigere README med en ny commit gennem browseren, og dermed simulere parallelt arbejde. Det er, som om nogen lavede ændringer i den samme fil, mens vi arbejdede på den. Resultatet bliver en konflikt. Vi fjerner ordet "fully" fra linje 10.

Implementer vores funktionalitet

Vores opgave er at ændre README og tilføje en beskrivelse til den nye artikel. Det vil sige, at arbejdet i Git går gennem IntelliJ IDEA. Tilføj dette:

Ændringerne er udført. Nu kan vi oprette en commit. Tryk på CTRL+K , hvilket giver os:

Før du opretter en commit, skal vi se nærmere på, hvad dette vindue byder på.

I sektionen Commit Message skriver vi tekst forbundet med commit. Derefter skal vi klikke på Commit for at oprette det .

Vi skriver, at README har ændret sig og opretter commit. En advarsel dukker op i nederste venstre hjørne med navnet på forpligtelsen:

Tjek om hovedgrenen er ændret

Vi udførte vores opgave. Det virker. Vi skrev prøver. Alt er fint. Men før vi skubber til serveren, skal vi stadig tjekke, om der var ændringer i hovedgrenen i mellemtiden. Hvordan kunne det ske? Ganske nemt: nogen modtager en opgave efter dig, og at nogen afslutter den hurtigere, end du afslutter din opgave.

Så vi er nødt til at gå til mestergrenen. For at gøre dette skal vi gøre det, der er vist i nederste højre hjørne på skærmbilledet nedenfor:

I mastergrenen skal du trykke på CTRL+T for at få de seneste ændringer fra fjernserveren. Når du ser på ændringerne, kan du nemt se, hvad der skete:

Ordet "fully" blev fjernet. Måske har nogen fra marketing besluttet, at det ikke skulle skrives sådan, og gav udviklerne en opgave om at opdatere det.

Vi har nu en lokal kopi af den seneste version af masterfilialen. Gå tilbage til readme-improver .

Nu skal vi ombase ændringerne fra mastergrenen til vores. Vi gør dette:

Hvis du gjorde alt korrekt og fulgte med mig, skulle resultatet vise en konflikt i README-filen:

Her har vi også en masse information at forstå og suge til os. Her vises en liste over filer (i vores tilfælde en fil), der har konflikter. Vi kan vælge mellem tre muligheder:

1. accepter din - accepter kun ændringer fra readme-improver.
2. accepter deres — accepter kun ændringer fra master.
3. flette — vælg selv, hvad du vil beholde, og hvad du vil kassere.

Det er ikke klart, hvad der har ændret sig. Hvis der er ændringer i mastergrenen, skal de være nødvendige der, så vi kan ikke bare acceptere vores ændringer. Derfor vælger vi fletning :

Her kan vi se, at der er tre dele:

1. Disse er ændringerne fra readme-improver.
2. Det sammenlagte resultat. For nu er det, hvad der eksisterede før ændringerne.
3. Ændringerne fra mastergrenen.

Vi skal skabe et sammenlagt resultat, der vil tilfredsstille alle. Når vi gennemgår, hvad der blev ændret FØR vores ændringer, indser vi, at de simpelthen fjernede ordet "fully". Okay intet problem! Det betyder, at vi også vil fjerne det i det flettede resultat og derefter tilføje vores ændringer. Når vi har rettet det flettede resultat, kan vi klikke på Anvend .

Så dukker der en meddelelse op, der fortæller os, at rebasen var vellykket:

Der! Vi løste vores første konflikt gennem IntelliJ IDEA.

Push ændringer til fjernserveren

Det næste trin er at skubbe ændringerne til fjernserveren og oprette en pull-anmodning. For at gøre dette skal du blot trykke på CTRL+SHIFT+K . Så får vi:

Til venstre vil der være en liste over commits, der ikke er blevet skubbet til fjernlageret. Til højre vil være alle de filer, der er ændret. Og det er det! Tryk på Push og du vil opleve lykke :)

Hvis push er vellykket, vil du se en notifikation som denne i nederste højre hjørne:

Bonus: oprettelse af en pull-anmodning

Lad os gå til et GitHub-lager, og vi ser, at GitHub allerede ved, hvad vi vil have:

Klik på Sammenlign og træk anmodning . Klik derefter på Opret pull request . Fordi vi løste konflikterne på forhånd, kan vi nu, når vi opretter en pull-anmodning, straks flette den:

Det var det for nu!