Komme i gang med Git: en omfattende guide for nybegynnere

I stedet for en introduksjon

Hallo! I dag skal vi snakke om et versjonskontrollsystem, nemlig Git. Du har ingenting med programmering å gjøre hvis du ikke kjenner/forstår Git. Men det fine er at du ikke trenger å ha alle Git-kommandoene og funksjonene i hodet for å være kontinuerlig ansatt. Du må kjenne til et sett med kommandoer som vil hjelpe deg å forstå alt som skjer.

Grunnleggende om Git

Git er et distribuert versjonskontrollsystem for koden vår. Hvorfor trenger vi det? Distribuerte team trenger et slags system for å administrere arbeidet sitt. Det er nødvendig å spore endringer som skjer over tid. Det vil si at vi må kunne se trinn for trinn hvilke filer som har endret seg og hvordan. Dette er spesielt viktig når du undersøker hva som endret seg i sammenheng med en enkelt oppgave, noe som gjør det mulig å tilbakestille endringene.

Installerer Git

La oss installere Java på datamaskinen din.

Installerer på Windows

Som vanlig må du laste ned og kjøre en exe-fil. Alt er enkelt her: klikk på den første Google-lenken , utfør installasjonen, og det er det. For å gjøre dette bruker vi bash-konsollen levert av Windows. På Windows må du kjøre Git Bash. Slik ser det ut i Start-menyen: Nå er dette en ledetekst du kan jobbe med. For å unngå å måtte gå til mappen med prosjektet hver gang for å åpne Git der, kan du åpne ledeteksten i prosjektmappen med høyre museknapp med banen vi trenger:

Installerer på Linux

Vanligvis er Git en del av Linux-distribusjoner og er allerede installert, siden det er et verktøy som opprinnelig ble skrevet for Linux-kjerneutvikling. Men det er situasjoner når det ikke er det. For å sjekke, må du åpne en terminal og skrive: git --version. Hvis du får et forståelig svar, trenger du ingenting å installere. Åpne en terminal og installer Git på Ubuntu . Jeg jobber med Ubuntu, så jeg kan fortelle deg hva du skal skrive for det: sudo apt-get install git.

Installerer på macOS

Også her må du først sjekke om Git allerede er der. Hvis du ikke har det, så er den enkleste måten å få det på å laste ned den nyeste versjonen her . Hvis Xcode er installert, vil Git definitivt bli installert automatisk.

Git-innstillinger

Git har brukerinnstillinger for brukeren som skal sende inn arbeid. Dette gir mening og er nødvendig, fordi Git tar denne informasjonen for Author-feltet når en commit opprettes. Sett opp et brukernavn og passord for alle prosjektene dine ved å kjøre følgende kommandoer:

git config --global user.name "Ivan Ivanov"
git config --global user.email ivan.ivanov@gmail.com

Hvis du trenger å endre forfatteren for et spesifikt prosjekt, kan du fjerne "--global". Dette vil gi oss følgende:

git config user.name "Ivan Ivanov"
git config user.email ivan.ivanov@gmail.com

Litt teori...

For å dykke inn i emnet bør vi introdusere deg for noen få nye ord og handlinger...

• git repository
• begå
• gren
• slå sammen
• konflikter
• dra
• trykk
• hvordan ignorere noen filer (.gitignore)

Og så videre.

Statuser i Git

Git har flere statuer som må forstås og huskes:

• usporet
• modifisert
• iscenesatt
• engasjert

Hvordan skal du forstå dette?

Dette er statuser som gjelder for filene som inneholder koden vår:

1. En fil som er opprettet, men som ennå ikke er lagt til i depotet, har statusen "usporet".
2. Når vi gjør endringer i filer som allerede er lagt til i Git-depotet, blir statusen deres "modifisert".
3. Blant filene vi har endret, velger vi de vi trenger, og disse klassene blir endret til "iscenesatt" status.
4. En commit opprettes fra forberedte filer i trinnvis tilstand og går inn i Git-depotet. Etter det er det ingen filer med "iscenesatt" status. Men det kan fortsatt være filer hvis status er "endret".

Slik ser det ut:

Hva er en forpliktelse?

En commit er hovedbegivenheten når det kommer til versjonskontroll. Den inneholder alle endringene som er gjort siden forpliktelsen startet. Forpliktelser er koblet sammen som en enkeltlenket liste. Mer spesifikt: Det er en første forpliktelse. Når den andre forpliktelsen er opprettet, vet den hva som kommer etter den første. Og på denne måten kan informasjon spores. En commit har også sin egen informasjon, såkalte metadata:

• forpliktelsens unike identifikator, som kan brukes til å finne den
• navnet på forpliktelsens forfatter, som opprettet den
• datoen forpliktelsen ble opprettet
• en kommentar som beskriver hva som ble gjort under forpliktelsen

Slik ser det ut:

Hva er en gren?

En gren er en pekepinn til en forpliktelse. Fordi en commit vet hvilken commit som går foran den, når en gren peker på en commit, gjelder alle de tidligere commitene også for den. Følgelig kan vi si at du kan ha så mange grener du vil som peker på samme commit. Arbeid skjer i grener, så når en ny commit opprettes, flytter grenen pekeren til den nyere commit.

Komme i gang med Git

Du kan jobbe med et lokalt depot alene så vel som med et eksternt. For å praktisere de nødvendige kommandoene kan du begrense deg til det lokale depotet. Den lagrer kun all prosjektets informasjon lokalt i .git-mappen. Hvis vi snakker om det eksterne depotet, så er all informasjonen lagret et sted på den eksterne serveren: bare en kopi av prosjektet lagres lokalt. Endringer som er gjort i din lokale kopi kan skyves (git push) til det eksterne depotet. I diskusjonen vår her og nedenfor snakker vi om å jobbe med Git i konsollen. Selvfølgelig kan du bruke en slags GUI-basert løsning (for eksempel IntelliJ IDEA), men først bør du finne ut hvilke kommandoer som blir utført og hva de betyr.

Arbeide med Git i et lokalt depot

Deretter foreslår jeg at du følger med og utfører alle trinnene jeg gjorde mens du leste artikkelen. Dette vil forbedre din forståelse og mestring av materialet. Vel, god appetitt! :) For å opprette et lokalt depot, må du skrive:

git init

Dette vil opprette en .git-mappe i konsollens gjeldende katalog. .git-mappen lagrer all informasjon om Git-depotet. Ikke slett det ;) Deretter legges filer til prosjektet, og de får statusen "Usporet". For å sjekke gjeldende status for arbeidet ditt, skriv dette:

git status

Vi er i mestergrenen, og her blir vi værende til vi bytter til en annen gren. Dette viser hvilke filer som har endret seg, men som ennå ikke er lagt til "iscenesatt" status. For å legge dem til "iscenesatt"-status, må du skrive "git add". Vi har noen alternativer her, for eksempel:

• git add -A — legg til alle filene til "iscenesatt" status
• git legg til. - legg til alle filer fra denne mappen og alle undermapper. I hovedsak er dette det samme som den forrige
• git add <filnavn> – legger til en spesifikk fil. Her kan du bruke regulære uttrykk for å legge til filer etter et eller annet mønster. For eksempel git add *.java: Dette betyr at du bare vil legge til filer med java-utvidelsen.

De to første alternativene er helt klart enkle. Ting blir mer interessant med det siste tilskuddet, så la oss skrive:

git add *.txt

For å sjekke statusen bruker vi kommandoen som allerede er kjent for oss:

git status

Her kan du se at det regulære uttrykket har fungert riktig: test_resource.txt har nå statusen "stadium". Og til slutt, den siste fasen for å jobbe med et lokalt depot (det er en til når du arbeider med det eksterne depotet ;)) — å lage en ny forpliktelse:

git commit -m "all txt files were added to the project"

Neste opp er en flott kommando for å se på forpliktelseshistorien på en gren. La oss bruke det:

git log

Her kan du se at vi har opprettet vår første forpliktelse, og den inkluderer teksten vi ga på kommandolinjen. Det er veldig viktig å forstå at denne teksten skal forklare så nøyaktig som mulig hva som ble gjort under denne forpliktelsen. Dette vil hjelpe oss mange ganger i fremtiden. En nysgjerrig leser som ennå ikke har sovnet, lurer kanskje på hva som skjedde med GitTest.java-filen. La oss finne ut av det nå. For å gjøre dette bruker vi:

git status

Som du ser er den fortsatt "usporet" og venter i kulissene. Men hva om vi ikke vil legge det til prosjektet i det hele tatt? Noen ganger skjer det. For å gjøre ting mer interessant, la oss nå prøve å endre test_resource.txt-filen vår. La oss legge til litt tekst der og sjekke statusen:

git status

Her kan du tydelig se forskjellen mellom "usporet" og "modifisert" status. GitTest.java er "usporet", mens test_resource.txt er "modifisert". Nå som vi har filer i modifisert tilstand, kan vi undersøke endringene som er gjort i dem. Dette kan gjøres ved å bruke følgende kommando:

git diff

Det vil si at du tydelig kan se her hva jeg la til tekstfilen vår: hei verden! La oss legge til endringene våre i tekstfilen og lage en forpliktelse:

git add test_resource.txt
git commit -m "added hello word! to test_resource.txt"

For å se på alle forpliktelser, skriv:

git log

Som du kan se, har vi nå to commits. Vi legger til GitTest.java på samme måte. Ingen kommentarer her, bare kommandoer:

git add GitTest.java
git commit -m "added GitTest.java"
git status

Arbeider med .gitignore

Det er klart at vi bare ønsker å beholde kildekoden alene, og ingenting annet, i depotet. Så hva annet kan det være? Som et minimum, kompilerte klasser og/eller filer generert av utviklingsmiljøer. For å fortelle Git å ignorere dem, må vi lage en spesiell fil. Gjør dette: lag en fil kalt .gitignore i roten av prosjektet. Hver linje i denne filen representerer et mønster som skal ignoreres. I dette eksemplet vil .gitignore-filen se slik ut:

```
*.class
target/
*.iml
.idea/
```

La oss ta en titt:

• Den første linjen er å ignorere alle filer med filtypen .class
• Den andre linjen er å ignorere "mål"-mappen og alt den inneholder
• Den tredje linjen er å ignorere alle filer med filtypen .iml
• Den fjerde linjen er å ignorere .idea-mappen

La oss prøve å bruke et eksempel. For å se hvordan det fungerer, la oss legge til den kompilerte GitTest.class til prosjektet og sjekke prosjektstatusen:

git status

Det er klart at vi ikke ønsker å legge til den kompilerte klassen ved et uhell i prosjektet (ved å bruke git add -A). For å gjøre dette, lag en .gitignore-fil og legg til alt som ble beskrevet tidligere: La oss nå bruke en commit for å legge til .gitignore-filen til prosjektet:

git add .gitignore
git commit -m "added .gitignore file"

Og nå sannhetens øyeblikk: vi har en kompilert klasse GitTest.class som er "usporet", som vi ikke ønsket å legge til Git-depotet. Nå bør vi se effekten av .gitignore-filen:

git status

Perfekt! .gitignore +1 :)

Jobber med grener og slikt

Naturligvis er det upraktisk å jobbe i én gren for ensomme utviklere, og det er umulig når det er mer enn én person på et team. Det er derfor vi har filialer. Som jeg sa tidligere, er en gren bare en bevegelig pekepinn til forpliktelser. I denne delen skal vi utforske arbeid i forskjellige grener: hvordan slå sammen endringer fra en gren til en annen, hvilke konflikter som kan oppstå og mye mer. For å se en liste over alle grenene i depotet og forstå hvilken du er i, må du skrive:

git branch -a

Du kan se at vi bare har en mastergren. Stjernen foran indikerer at vi er i den. Du kan forresten også bruke kommandoen "git status" for å finne ut hvilken gren vi er i. Så er det flere alternativer for å lage grener (det kan være flere — dette er de jeg bruker):

• opprette en ny filial basert på den vi er i (99 % av tilfellene)
• opprette en filial basert på en spesifikk forpliktelse (1 % av tilfellene)

La oss lage en gren basert på en spesifikk forpliktelse

Vi vil stole på forpliktelsens unike identifikator. For å finne den skriver vi:

git log

Jeg har fremhevet forpliktelsen med kommentaren "added hello world..." Dens unike identifikator er 6c44e53d06228f888f2f454d3cb8c1c976dd73f8. Jeg ønsker å lage en "utviklings"-gren som starter fra denne forpliktelsen. For å gjøre dette skriver jeg:

git checkout -b development 6c44e53d06228f888f2f454d3cb8c1c976dd73f8

En gren opprettes med kun de to første commitene fra mastergrenen. For å bekrefte dette, sørger vi først for å bytte til en annen filial og ser på antall forpliktelser der:

git status
git log

Og som forventet har vi to forpliktelser. Forresten, her er et interessant poeng: det er ingen .gitignore-fil i denne grenen ennå, så vår kompilerte fil (GitTest.class) er nå uthevet med "usporet"-status. Nå kan vi gå gjennom avdelingene våre igjen ved å skrive dette:

git branch -a

Du kan se at det er to grener: «master» og «utvikling». Vi er for tiden i utvikling.

La oss lage en gren basert på den nåværende

Den andre måten å lage en gren på er å lage den fra en annen. Jeg vil lage en gren basert på mastergrenen. Først må jeg bytte til det, og neste trinn er å lage en ny. La oss ta en titt:

• git checkout master — bytt til mastergrenen
• git status — bekreft at vi faktisk er i mastergrenen

Her kan du se at vi byttet til mastergrenen, .gitignore-filen er i kraft, og den kompilerte klassen er ikke lenger uthevet som "usporet". Nå lager vi en ny gren basert på mastergrenen:

git checkout -b feature/update-txt-files

Hvis du er usikker på om denne grenen er det samme som "master", kan du enkelt sjekke ved å kjøre "git log" og se på alle commitene. Det skal være fire av dem.

Konfliktløsning

Før vi utforsker hva en konflikt er, må vi snakke om å slå sammen en gren til en annen. Dette bildet viser prosessen med å slå sammen en gren til en annen: Her har vi en hovedgren. På et tidspunkt blir en sekundær gren opprettet av hovedgrenen og deretter modifisert. Når arbeidet er gjort, må vi slå sammen den ene grenen til den andre. Jeg vil ikke beskrive de ulike funksjonene: I denne artikkelen ønsker jeg kun å formidle en generell forståelse. Hvis du trenger detaljene, kan du slå dem opp selv. I vårt eksempel opprettet vi grenen feature/update-txt-files. Som indikert av navnet på filialen, oppdaterer vi teksten. Nå må vi opprette en ny forpliktelse for dette arbeidet:

git add *.txt 
git commit -m "updated txt files"
git log

Nå, hvis vi ønsker å slå sammen feature/update-txt-files-grenen til master, må vi gå til master og skrive "git merge feature/update-txt-files":

git checkout master
git merge feature/update-txt-files
git log

Som et resultat inkluderer mastergrenen nå også forpliktelsen som ble lagt til feature/update-txt-filer. Denne funksjonaliteten ble lagt til, slik at du kan slette en funksjonsgren. For å gjøre dette skriver vi:

git branch -D feature/update-txt-files

Alt er klart så langt, ikke sant? La oss komplisere situasjonen: la oss nå si at du må endre txt-filen igjen. Men nå skal denne filen endres i mastergrenen også. Det vil med andre ord endre seg parallelt. Git vil ikke være i stand til å finne ut hva vi skal gjøre når vi ønsker å slå sammen vår nye kode inn i mastergrenen. La oss gå! Vi oppretter en ny gren basert på master, gjør endringer i text_resource.txt og oppretter en forpliktelse for dette arbeidet:

git checkout -b feature/add-header
... we make changes to the file

git add *.txt
git commit -m "added header to txt"

Gå til hovedgrenen og oppdater også denne tekstfilen på samme linje som i funksjonsgrenen:

git checkout master
… we updated test_resource.txt

git add test_resource.txt
git commit -m "added master header to txt"

Og nå det mest interessante poenget: vi må slå sammen endringer fra funksjonen/add-header-grenen til master. Vi er i mastergrenen, så vi trenger bare å skrive:

git merge feature/add-header

Men resultatet vil være en konflikt i test_resource.txt-filen: Her kan vi se at Git ikke kunne bestemme på egen hånd hvordan denne koden skulle slås sammen. Det forteller oss at vi må løse konflikten først, og først deretter utføre forpliktelsen. OK. Vi åpner filen med konflikten i et tekstredigeringsprogram og ser: For å forstå hva Git gjorde her, må vi huske hvilke endringer vi gjorde og hvor, og deretter sammenligne:

1. Endringene som var på denne linjen i mastergrenen finnes mellom "<<<<<<< HEAD" og "=======".
2. Endringene som var i grenen feature/add-header finnes mellom "=======" og ">>>>>>> feature/add-header.

Dette er hvordan Git forteller oss at den ikke kunne finne ut hvordan den skulle utføre sammenslåingen på dette stedet i filen. Den delte denne delen inn i to deler fra de forskjellige grenene og inviterer oss til å løse sammenslåingskonflikten selv. Greit nok. Jeg bestemmer meg frimodig for å fjerne alt, og etterlater bare ordet "header": La oss se på statusen til endringene. Beskrivelsen vil være litt annerledes. I stedet for en "modifisert" status, har vi "unfusion". Så kunne vi ha nevnt en femte status? Jeg tror ikke dette er nødvendig. La oss se:

git status

Vi kan overbevise oss selv om at dette er en spesiell, uvanlig sak. La oss fortsette:

git add *.txt

Du kan legge merke til at beskrivelsen foreslår å skrive bare "git commit". La oss prøve å skrive det:

git commit

Og akkurat som det gjorde vi det - vi løste konflikten i konsollen. Dette kan selvsagt gjøres litt enklere i integrerte utviklingsmiljøer. For eksempel, i IntelliJ IDEA er alt satt opp så godt at du kan utføre alle nødvendige handlinger rett innenfor det. Men IDE-er gjør mange ting "under panseret", og vi forstår ofte ikke hva som skjer der. Og når det ikke er forståelse, kan det oppstå problemer.

Arbeider med eksterne depoter

Det siste trinnet er å finne ut noen flere kommandoer som er nødvendige for å fungere med det eksterne depotet. Som jeg sa, et eksternt depot er et sted hvor depotet er lagret og hvorfra du kan klone det. Hva slags eksterne depoter finnes det? Eksempler:

• GitHub er den største lagringsplattformen for repositories og samarbeidsutvikling. Jeg har allerede beskrevet det i tidligere artikler.
  Følg meg på GitHub . Jeg viser ofte frem arbeidet mitt der i de områdene jeg studerer for arbeid.

• GitLab er et nettbasert verktøy for DevOps- livssyklusen med åpen kildekode . Det er et Git -basert system for å administrere kodelagre med sin egen wiki, feilsporingssystem , CI/CD-pipeline og andre funksjoner.
  Etter nyheten om at Microsoft kjøpte GitHub, dupliserte noen utviklere prosjektene sine i GitLab.

• BitBucket er en webtjeneste for prosjektvert og samarbeidsutvikling basert på Mercurial og Git versjonskontrollsystemer. På et tidspunkt hadde den en stor fordel fremfor GitHub ved at den tilbød gratis private depoter. I fjor introduserte GitHub også denne muligheten for alle gratis.

• Og så videre…

Når du arbeider med et eksternt depot, er den første tingen å gjøre å klone prosjektet til ditt lokale depot. For dette eksporterte jeg prosjektet som vi laget lokalt, og nå kan alle klone det for seg selv ved å skrive:

git clone https://github.com/romankh3/git-demo

Det finnes nå en komplett lokal kopi av prosjektet. For å være sikker på at den lokale kopien av prosjektet er den nyeste, må du trekke prosjektet ved å skrive:

git pull

I vårt tilfelle er ingenting i fjernlageret endret for øyeblikket, så svaret er: Allerede oppdatert. Men hvis jeg gjør noen endringer i det eksterne depotet, oppdateres det lokale etter at vi henter dem. Og til slutt, den siste kommandoen er å skyve dataene til det eksterne depotet. Når vi har gjort noe lokalt og ønsker å sende det til fjernlageret, må vi først opprette en ny commit lokalt. For å demonstrere dette, la oss legge til noe annet i tekstfilen vår: Nå er det noe som er ganske vanlig for oss - vi oppretter en forpliktelse for dette arbeidet:

git add test_resource.txt
git commit -m "prepared txt for pushing"

Kommandoen for å skyve dette til det eksterne depotet er:

git push

Vel, det var alt jeg ville si. Takk for oppmerksomheten. Følg meg på GitHub , hvor jeg legger ut ulike kule eksempelprosjekter knyttet til mitt personlige studium og arbeid.

Nyttig link

• Offisiell Git-dokumentasjon . Jeg anbefaler det som referanse.