En match made in heaven: Git og IntelliJ IDEA

Ved at holde fast i den etablerede tradition hilser jeg dig som fremtidige senior softwareingeniører. Dagens artikel er den logiske forlængelse af min artikel om Git . I artiklen om Git beskrev jeg, hvordan man arbejder med Git på kommandolinjen. I dag vil jeg vise dig, hvordan du gør det hele i IntelliJ IDEA. I begyndelsen af ​​min rejse som udvikler brugte jeg kommandolinjen og tænkte, at jeg ikke behøvede en GUI til dette. Alt var jo klart, som det var... Men det var lige indtil det øjeblik, hvor jeg begyndte at bruge Git i IntelliJ IDEA... Fra starten vil jeg sige, at jeg beskriver min personlige oplevelse. Der er flere måder at løse et givet problem på i IntelliJ IDEA. Hvis du kender en bedre måde end det, jeg vil beskrive i artiklen, så skriv det i kommentarerne, så diskuterer vi det.

Nødvendige input:

1. Læs, følg med og forstå min artikel om Git . Dette vil hjælpe med at sikre, at alt er sat op og klar til at gå.
2. Installer IntelliJ IDEA.
3. Tildel en times personlig tid for at opnå fuldstændig beherskelse.

Lad os arbejde med demoprojektet , som jeg brugte til artiklen om Git. OPDATERING:På udgivelsestidspunktet vil den nye GitHub UI være tilgængelig, og nogle ikoner vil ikke være der, hvor de vises i artiklen. Bliv ikke foruroliget: Du skal bare enten ikke skifte til den nye brugergrænseflade eller lede efter dem.

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.
2. Klon mit lager og gør alt lokalt uden mulighed for at skubbe det hele til serveren. Dette er trods alt mit lager :)

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

1. Kopiér projektadressen:

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, og det er uden for rammerne af denne artikel, 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 til én. Og i midten har vi det endelige sammenlagte resultat. Når et projekt har mange filialer, commits og brugere, skal du søge separat på filial, bruger og dato: Det sidste, jeg vil forklare, før vi starter, er, hvordan du forstår, hvilken branche vi er i. Jeg vil give dig et minut til at finde ud af det... Fandt du det? Give op? :D 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:

0. CTRL+T — Hent de seneste ændringer fra fjernlageret (git pull).
1. CTRL+K — Opret en commit/se alle de aktuelle ændringer. Dette inkluderer både usporede og ændrede filer (se min artikel om git, som forklarer dette) (git commit).
2. 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).
3. 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 rammerne af denne artikel). 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.

Hvad der kommer derefter afhænger af dine opgaver og din fantasi.

Vil du få ændringer fra fjernserveren?

Jeg tilføjede 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.

1. 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. For mig vil det være readme-forbedrer .

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

Lad os simulere parallelt arbejde

For at konflikter skal dukke op, skal nogen oprette dem :D Jeg vil redigere README med en ny commit gennem browseren, og dermed simulere parallelt arbejde. Det er, som om nogen har lavet ændringer i den samme fil, mens jeg arbejdede på den. Resultatet bliver en konflikt. Jeg 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å. Jeg tilføjede røde pile for at vise dig, hvor du skal kigge. Der er mange interessante ting her. I sektionen Commit Message skriver vi tekst forbundet med commit. Så for at oprette det, skal vi klikke på Commit. Jeg har stadig ikke fundet ud af, hvordan man gør dette med en genvejstast. Hvis nogen finder ud af hvordan, så skriv til mig - det ville gøre mig meget glad. 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 i 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. Det gør vi: Hvis du gjorde alt rigtigt og fulgte med mig, skulle resultatet vise en konflikt i README filen: Her har vi også en masse information at forstå og opsuge. 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 :D

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 skubningen lykkes, vil du se en notifikation som denne i nederste højre hjørne:

Bonus del

Først ville jeg ikke tilføje oprettelsen af ​​en pull-anmodning til denne artikel, men den er ikke helt komplet uden den. Så lad os gå til et GitHub-lager (et, der er dit, selvfølgelig :)), 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 slå den sammen: Og det var alt, hvad jeg ville sige denne gang. Jeg har selvfølgelig kun åbnet døren lidt for dig og vist dig en lille del. Du lærer om resten, efterhånden som du har brug for det. Jeg har for vane at invitere dig til at følge mig på GitHub, hvor jeg poster mine projekter, der involverer forskellige teknologier, som jeg bruger på arbejdet. Jeg har for nylig opnået en personlig præstation: Et af mine projekter fik stjerner af mere end hundrede udviklere. Der er en utrolig følelse af glæde, når man ved, at det, man har gjort, bliver brugt af en anden. Og bruge det til gode.

Nyttige links

1. CodeGym: Kom godt i gang med Git: en omfattende guide til nybegyndere
2. GitHub: Demoprojekt til praksis
3. JetBrains: Opsæt et Git Repository
4. GitHub: Min konto