En match made in heaven: Git och IntelliJ IDEA

Jag håller fast vid den etablerade traditionen och hälsar dig som framtida senior mjukvaruingenjörer. Dagens artikel är den logiska förlängningen av min artikel om Git . I artikeln om Git beskrev jag hur man arbetar med Git på kommandoraden. Idag kommer jag att visa dig hur du gör allt i IntelliJ IDEA. I början av min resa som utvecklare använde jag kommandoraden och tänkte att jag inte behövde något GUI för detta. Allt var trots allt klart som det var... Men det var ända fram till det ögonblick då jag började använda Git i IntelliJ IDEA... Redan från början vill jag säga att jag beskriver min personliga upplevelse. Det finns flera sätt att lösa ett givet problem i IntelliJ IDEA. Om du vet ett bättre sätt än vad jag kommer att beskriva i artikeln, skriv det i kommentarerna så diskuterar vi det.

Nödvändiga ingångar:

1. Läs, följ med och förstå min artikel om Git . Detta kommer att hjälpa till att säkerställa att allt är inställt och redo att gå.
2. Installera IntelliJ IDEA.
3. Tilldela en timmes personlig tid för att uppnå fullständig behärskning.

Låt oss arbeta med demoprojektet som jag använde för artikeln om Git. UPPDATERING:Vid tidpunkten för publiceringen kommer det nya GitHub-gränssnittet att vara tillgängligt, och vissa ikoner kommer inte att finnas där de visas i artikeln. Var inte orolig: du behöver bara antingen inte byta till det nya användargränssnittet eller leta efter dem.

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.
2. Klona mitt förråd och gör allt lokalt utan möjlighet att skicka det hela till servern. Detta är trots allt mitt förråd :)

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 och det ligger utanför ramen för denna artikel, väljer vi Skapa projekt från befintliga källor :

6. Därefter kommer du att se den här vackra skärmen: 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: Det sista jag vill förklara innan vi börjar är hur man förstår vilken gren vi är i. Jag ska ge dig en minut att ta reda på det... Hittade du det? Ge upp? :D 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:

0. CTRL+T — Hämta de senaste ändringarna från fjärrförvaret (git pull).
1. CTRL+K — Skapa en commit/se alla aktuella ändringar. Detta inkluderar både ospårade och modifierade filer (se min artikel om git, som förklarar detta) (git commit).
2. 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).
3. 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-begäran till huvudgrenen, men det ligger utanför den här artikelns räckvidd). 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.

Vad som kommer härnäst beror på dina uppgifter och din fantasi.

Få ändringar från fjärrservern?

Jag lade 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. Ange 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.

1. 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. För mig kommer det 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 dyka upp måste någon skapa dem :D Jag 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 jag arbetade med den. Resultatet blir en konflikt. Jag 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. Jag lade till röda pilar för att visa dig var du ska leta. Det finns mycket intressant här. I avsnittet Commit Message skriver vi text som är kopplad till commit. Sedan för att skapa den måste vi klicka på Commit. Jag har fortfarande inte fått reda på hur man gör detta med en snabbtangent. Om någon får reda på hur, skriv till mig - det skulle göra mig väldigt glad. 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 mastergrenen, tryck CTRL+T för att få 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 har gjort allt rätt och följt med mig bör resultatet visa en konflikt i README-filen: Här har vi också mycket information att förstå och suga in. 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 :D

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 pushats till fjärrförvaret. Till höger kommer alla filer som har ändrats. Och det är allt! Tryck Push och du kommer att uppleva lycka :) Om pushen lyckas kommer du att se ett meddelande så här i det nedre högra hörnet:

Bonus del

Först ville jag inte lägga till skapandet av en pull-förfrågan i den här artikeln, men den är inte helt komplett utan den. Så, låt oss gå till ett GitHub-förråd (ett som är ditt, naturligtvis :)) 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, när vi nu skapar en pull-förfrågan, kan vi omedelbart slå samman den: Och det var allt jag ville säga den här gången. Självklart har jag bara öppnat dörren lite för dig och visat en liten del. Du kommer att lära dig om resten när du behöver det. Jag har för vana att bjuda in dig att följa mig på GitHub, där jag lägger upp mina projekt som involverar olika tekniker som jag använder på jobbet. Jag gjorde nyligen en personlig prestation: ett av mina projekt fick stjärnor av mer än hundra utvecklare. Det blir en otrolig känsla av glädje när man vet att det man har gjort används av någon annan. Och använder det för gott.

Användbara länkar

1. CodeGym: Komma igång med Git: en omfattande guide för nybörjare
2. GitHub: Demoprojekt för övning
3. JetBrains: Skapa ett Git-förråd
4. GitHub: Mitt konto