Nødvendige input:
- 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å.
- Installer IntelliJ IDEA.
- Tildel en times personlig tid for at opnå fuldstændig beherskelse.
Klon projektet lokalt
Der er to muligheder her:- Hvis du allerede har en GitHub-konto og vil skubbe noget senere, er det bedre at forgrene projektet og klone din egen kopi.
- Klon mit lager og gør alt lokalt uden mulighed for at skubbe det hele til serveren. Dette er trods alt mit lager :)
-
Kopiér projektadressen:
-
Åbn IntelliJ IDEA og vælg "Get from Version Control":
-
Kopiér og indsæt projektadressen:
-
Du vil blive bedt om at oprette et IntelliJ IDEA-projekt. Accepter tilbuddet:
-
Da der ikke er noget byggesystem, og det er uden for rammerne af denne artikel, vælger vi Opret projekt fra eksisterende kilder :
-
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:- CTRL+T — Hent de seneste ændringer fra fjernlageret (git pull).
- 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).
- 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).
- 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?-
Få alle de aktuelle ændringer i hovedgrenen (for eksempel "master").
-
Fra denne hovedgren skal du oprette en separat gren til dit arbejde.
-
Implementer den nye funktionalitet.
-
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 ).
- Skub dine ændringer til fjernlageret.
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.-
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:- accepter din - accepter kun ændringer fra readme-improver.
- accepter deres — accepter kun ændringer fra master.
- flette — vælg selv, hvad du vil beholde, og hvad du vil kassere.
- Disse er ændringerne fra readme-improver.
- Det sammenlagte resultat. For nu er det, hvad der eksisterede før ændringerne.
- Ændringerne fra mastergrenen.