En match made in heaven: Git og IntelliJ IDEA

Ved å holde fast ved den etablerte tradisjonen hilser jeg dere som fremtidige senior programvareingeniører. Dagens artikkel er den logiske utvidelsen av artikkelen min om Git . I artikkelen om Git beskrev jeg hvordan du jobber med Git på kommandolinjen. I dag skal jeg vise deg hvordan du gjør alt i IntelliJ IDEA. I begynnelsen av min reise som utvikler brukte jeg kommandolinjen og tenkte at jeg ikke trengte en GUI for dette. Tross alt var alt klart som det var... Men det var helt frem til det øyeblikket jeg begynte å bruke Git i IntelliJ IDEA... Fra første stund vil jeg si at jeg beskriver min personlige opplevelse. Det er flere måter å løse et gitt problem i IntelliJ IDEA. Hvis du vet en bedre måte enn det jeg vil beskrive i artikkelen, skriv det i kommentarfeltet, så diskuterer vi det.

Nødvendige innganger:

1. Les, følg med og forstå artikkelen min om Git . Dette vil bidra til å sikre at alt er satt opp og klart til bruk.
2. Installer IntelliJ IDEA.
3. Tildel en time med personlig tid for å oppnå fullstendig mestring.

La oss jobbe med demoprosjektet som jeg brukte til artikkelen om Git. OPPDATER:På publiseringstidspunktet vil det nye GitHub-grensesnittet være tilgjengelig, og noen ikoner vil ikke være der de vises i artikkelen. Ikke bli skremt: du trenger bare enten å ikke bytte til det nye brukergrensesnittet, eller se etter dem.

Klon prosjektet lokalt

Det er to alternativer her:

1. Hvis du allerede har en GitHub-konto og ønsker å pushe noe senere, er det bedre å splitte prosjektet og klone din egen kopi.
2. Klone lageret mitt og gjør alt lokalt uten muligheten til å skyve hele greia til serveren. Tross alt er dette oppbevaringsstedet mitt :)

For å klone et prosjekt fra GitHub, må du kopiere prosjektlenken og sende den til IntelliJ IDEA:

1. Kopier prosjektadressen:

2. Åpne IntelliJ IDEA og velg "Få fra versjonskontroll":

3. Kopier og lim inn prosjektadressen:

4. Du vil bli bedt om å opprette et IntelliJ IDEA-prosjekt. Godta tilbudet:

5. Siden det ikke er noe byggesystem og det er utenfor rammen av denne artikkelen, velger vi Opprett prosjekt fra eksisterende kilder :

6. Deretter vil du se denne vakre skjermen: Nå som vi fant ut kloning, kan du ta en titt rundt.

Første blikk på IntelliJ IDEA som et Git UI

Ta en nærmere titt på det klonede prosjektet: du kan allerede få mye informasjon om versjonskontrollsystemet. Først har vi Versjonskontroll- panelet i nedre venstre hjørne. Her kan du finne alle lokale endringer og få en liste over commits (analogt med "git log"). La oss gå videre til en diskusjon av Log . Det er en viss visualisering som hjelper oss å forstå nøyaktig hvordan utviklingen har gått. For eksempel kan du se at en ny gren ble opprettet med en tilføyd overskrift til txt commit, som deretter ble slått sammen til hovedgrenen. Hvis du klikker på en forpliktelse, kan du se i høyre hjørne all informasjon om forpliktelsen: alle endringer og metadata.Dessuten kan du se de faktiske endringene. Vi ser også at en konflikt ble løst der. IDEA presenterer også dette veldig godt. Hvis du dobbeltklikker på filen som ble endret under denne commit, vil vi se hvordan konflikten ble løst: Vi legger merke til at til venstre og høyre har vi de to versjonene av samme fil som måtte slås sammen til én. Og i midten har vi det endelige sammenslåtte resultatet. Når et prosjekt har mange grener, forpliktelser og brukere, må du søke separat etter gren, bruker og dato: Det siste jeg vil forklare før vi starter er hvordan du forstår hvilken gren vi er i. Jeg skal gi deg et minutt på å finne ut av det... Fant du det? Gi opp? :D I nedre høyre hjørne er det en knapp merket Git: master. Det som følger etter "Git:" er den gjeldende grenen. Hvis du klikker på knappen, kan du gjøre mange nyttige ting: bytte til en annen gren, opprette en ny, gi nytt navn til en eksisterende, og så videre.

Arbeider med et depot

Nyttige hurtigtaster

For fremtidig arbeid må du huske noen svært nyttige hurtigtaster:

0. CTRL+T — Få de siste endringene fra fjernlageret (git pull).
1. CTRL+K — Opprett en forpliktelse / se alle gjeldende endringer. Dette inkluderer både usporede og modifiserte filer (se artikkelen min om git, som forklarer dette) (git commit).
2. CTRL+SHIFT+K — Dette er kommandoen for å skyve endringer til det eksterne depotet. Alle forpliktelser som er opprettet lokalt og ennå ikke er i det eksterne depotet, vil bli presset (git push).
3. ALT+CTRL+Z — Tilbakestill endringer i en spesifikk fil til tilstanden til den siste commit som ble opprettet i det lokale depotet. Hvis du velger hele prosjektet i øvre venstre hjørne, kan du rulle tilbake endringer i alle filer.

Hva vil vi?

For å få utført arbeid må vi mestre et grunnleggende scenario som brukes overalt. Målet er å implementere ny funksjonalitet i en egen gren og deretter skyve den til et eksternt depot (da må du også opprette en pull-forespørsel til hovedgrenen, men det er utenfor rammen av denne artikkelen). Hva kreves for å gjøre dette?

1. Få alle gjeldende endringer i hovedgrenen (for eksempel "master").

2. Fra denne hovedgrenen oppretter du en egen gren for arbeidet ditt.

3. Implementer den nye funksjonaliteten.

4. Gå til hovedavdelingen og sjekk om det har vært noen nye endringer mens vi jobbet. Hvis ikke, så er alt bra. Men hvis det var endringer, så gjør vi følgende: gå til arbeidsgrenen og rebase endringene fra hovedgrenen til vår. Hvis alt går bra, så flott. Men det er fullt mulig at det blir konflikter. Som det skjer, kan de bare løses på forhånd, uten å kaste bort tid i det eksterne depotet.

   Lurer du på hvorfor du bør gjøre dette? Det er god oppførsel og forhindrer konflikter fra å oppstå etter å ha presset filialen din til det lokale depotet (det er selvfølgelig en mulighet for at konflikter fortsatt vil oppstå, men det blir mye mindre).

5. Send endringene dine til det eksterne depotet.

Hva som kommer etterpå avhenger av oppgavene dine og fantasien din.

Vil du få endringer fra den eksterne serveren?

Jeg la til en beskrivelse i README med en ny forpliktelse og ønsker å få disse endringene. Hvis endringer ble gjort både i det lokale depotet og i det eksterne, er vi invitert til å velge mellom en sammenslåing og en rebase. Vi velger å slå sammen. Skriv inn CTRL+T : Du kan nå se hvordan README har endret seg, dvs. endringene fra fjernlageret ble trukket inn, og i nedre høyre hjørne kan du se alle detaljene om endringene som kom fra serveren.

Opprett en ny gren basert på master

Alt er enkelt her.

1. Gå til nederste høyre hjørne og klikk Git: master . Velg + Ny gren .

La avmerkingsboksen Checkout filial være valgt og skriv inn navnet på den nye filialen. For meg vil det være readme-forbedrer .

Git: master vil da endres til Git: readme-improver .

La oss simulere parallelt arbeid

For at konflikter skal dukke opp, må noen lage dem :D Jeg vil redigere README med en ny commit gjennom nettleseren, og simulerer dermed parallelt arbeid. Det er som om noen gjorde endringer i den samme filen mens jeg jobbet med den. Resultatet vil bli en konflikt. Jeg vil fjerne ordet "fully" fra linje 10.

Implementer funksjonaliteten vår

Vår oppgave er å endre README og legge til en beskrivelse til den nye artikkelen. Det vil si at arbeidet i Git går gjennom IntelliJ IDEA. Legg til dette: Endringene er gjort. Nå kan vi opprette en forpliktelse. Trykk CTRL+K , som gir oss: Før du oppretter en commit, må vi se nærmere på hva dette vinduet tilbyr. Jeg la til røde piler for å vise deg hvor du skal lete. Det er mye interessant her. I Commit Message- delen skriver vi tekst knyttet til commit. Så for å lage den, må vi klikke på Commit. Jeg har fortsatt ikke funnet ut hvordan jeg gjør dette med en hurtigtast. Hvis noen finner ut hvordan, vennligst skriv til meg - det ville gjort meg veldig glad. Vi skriver at README har endret seg og oppretter commit. Et varsel dukker opp i nedre venstre hjørne med navnet på forpliktelsen:

Sjekk om hovedgrenen er endret

Vi fullførte oppgaven vår. Det fungerer. Vi skrev prøver. Alt er bra. Men før vi skyver til serveren, må vi fortsatt sjekke om det var noen endringer i hovedgrenen i mellomtiden. Hvordan kunne det skje? Ganske enkelt: noen mottar en oppgave etter deg, og at noen fullfører den raskere enn du fullfører oppgaven. Så vi må gå til mestergrenen. For å gjøre dette, må vi gjøre det som er vist i nedre høyre hjørne i skjermbildet nedenfor: I hovedgrenen, trykk CTRL+T for å få de siste endringene fra den eksterne serveren. Når du ser på endringene, kan du enkelt se hva som skjedde:Ordet "fully" ble fjernet. Kanskje noen fra markedsføring bestemte at det ikke skulle skrives slik og ga utviklerne en oppgave om å oppdatere det. Vi har nå en lokal kopi av den nyeste versjonen av masterfilialen. Gå tilbake til readme-improver . Nå må vi rebase endringene fra mastergrenen til vår. Vi gjør dette: Hvis du gjorde alt riktig og fulgte med meg, skulle resultatet vise en konflikt i README-filen: Her har vi også mye informasjon å forstå og suge til oss. Her vises en liste over filer (i vårt tilfelle én fil) som har konflikter. Vi kan velge mellom tre alternativer:

1. godta din - godta kun endringer fra readme-improver.
2. godta deres — godta kun endringer fra master.
3. slå sammen – velg selv hva du vil beholde og hva du vil forkaste.

Det er ikke klart hva som endret seg. Hvis det er endringer i hovedgrenen, må de være nødvendige der, så vi kan ikke bare godta endringene våre. Følgelig velger vi sammenslåing : Her kan vi se at det er tre deler:

1. Dette er endringene fra readme-improver.
2. Det sammenslåtte resultatet. Foreløpig er det det som eksisterte før endringene.
3. Endringene fra mastergrenen.

Vi må produsere et sammenslått resultat som vil tilfredsstille alle. Når vi ser på hva som ble endret FØR endringene våre, innser vi at de ganske enkelt fjernet ordet "fully". Ok ikke noe problem! Det betyr at vi også vil fjerne det i det sammenslåtte resultatet og deretter legge til endringene våre. Når vi har korrigert det sammenslåtte resultatet, kan vi klikke på Bruk . Så dukker det opp et varsel som forteller oss at rebasen var vellykket: Der! Vi løste vår første konflikt gjennom IntelliJ IDEA :D

Push endringer til den eksterne serveren

Det neste trinnet er å skyve endringene til den eksterne serveren og opprette en pull-forespørsel. For å gjøre dette, trykk ganske enkelt CTRL+SHIFT+K . Så får vi: Til venstre vil det være en liste over forpliktelser som ikke har blitt pushet til det eksterne depotet. Til høyre vil være alle filene som er endret. Og det er det! Trykk Push og du vil oppleve lykke :) Hvis pushen er vellykket, vil du se et varsel som dette i nedre høyre hjørne:

Bonus del

Til å begynne med ønsket jeg ikke å legge til opprettelsen av en pull-forespørsel i denne artikkelen, men den er ikke helt komplett uten den. Så, la oss gå til et GitHub-lager (et som er ditt, selvfølgelig :)), og vi ser at GitHub allerede vet hva vi vil ha: Klikk Sammenlign og trekk forespørsel . Klikk deretter på Opprett pull request . Fordi vi løste konfliktene på forhånd, nå når vi oppretter en pull-forespørsel, kan vi umiddelbart slå den sammen: Og det var alt jeg ville si denne gangen. Jeg har selvfølgelig bare åpnet døren litt for deg og vist deg en liten del. Du vil lære om resten etter hvert som du trenger det. Jeg har for vane å invitere deg til å følge meg på GitHub, hvor jeg legger ut prosjektene mine som involverer ulike teknologier som jeg bruker på jobben. Jeg har nylig oppnådd en personlig prestasjon: ett av prosjektene mine ble gitt stjerner av mer enn hundre utviklere. Det er en utrolig gledesfølelse når du vet at det du har gjort blir brukt av noen andre. Og bruker det til gode.

Nyttige lenker

1. CodeGym: Komme i gang med Git: en omfattende guide for nybegynnere
2. GitHub: Demoprosjekt for praksis
3. JetBrains: Sett opp et Git Repository
4. GitHub: Min konto