Kom godt i gang med Git: en omfattende guide til nybegyndere

I stedet for en introduktion

Hej! I dag skal vi tale om et versionskontrolsystem, nemlig Git. Du har intet med programmering at gøre, hvis du ikke kender/forstår Git. Men det smukke er, at du ikke behøver at have alle Git-kommandoer og -funktioner i dit hoved for at være konstant ansat. Du skal kende et sæt kommandoer, der hjælper dig med at forstå alt, hvad der sker.

Grundlæggende om Git

Git er et distribueret versionskontrolsystem til vores kode. Hvorfor har vi brug for det? Distribuerede teams har brug for en form for system til at styre deres arbejde. Det er nødvendigt at spore ændringer, der opstår over tid. Det vil sige, at vi skal kunne se trin-for-trin, hvilke filer der er ændret og hvordan. Dette er især vigtigt, når du undersøger, hvad der ændrede sig i forbindelse med en enkelt opgave, hvilket gør det muligt at fortryde ændringerne.

Installation af Git

Lad os installere Java på din computer.

Installation på Windows

Som sædvanlig skal du downloade og køre en exe-fil. Alt er enkelt her: Klik på det første Google-link , udfør installationen, og det er det. For at gøre dette bruger vi bash-konsollen leveret af Windows. På Windows skal du køre Git Bash. Sådan ser det ud i startmenuen: Nu er dette en kommandoprompt, du kan arbejde med. For at undgå at skulle gå til mappen med projektet hver gang for at åbne Git der, kan du åbne kommandoprompten i projektmappen med højre museknap med den sti, vi skal bruge:

Installation på Linux

Normalt er Git en del af Linux-distributioner og er allerede installeret, da det er et værktøj, der oprindeligt blev skrevet til Linux-kerneudvikling. Men der er situationer, hvor det ikke er det. For at tjekke, skal du åbne en terminal og skrive: git --version. Hvis du får et forståeligt svar, skal der ikke installeres noget. Åbn en terminal og installer Git på Ubuntu . Jeg arbejder på Ubuntu, så jeg kan fortælle dig, hvad du skal skrive til det: sudo apt-get install git.

Installerer på macOS

Også her skal du først tjekke, om Git allerede er der. Hvis du ikke har det, så er den nemmeste måde at få det på at downloade den nyeste version her . Hvis Xcode er installeret, så vil Git helt sikkert blive installeret automatisk.

Git indstillinger

Git har brugerindstillinger for den bruger, der vil indsende arbejde. Dette giver mening og er nødvendigt, fordi Git tager denne information til feltet Author, når en commit oprettes. Konfigurer et brugernavn og en adgangskode til alle dine projekter ved at køre følgende kommandoer:

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

Hvis du har brug for at ændre forfatteren til et specifikt projekt, kan du fjerne "--global". Dette vil give os følgende:

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

Lidt teori...

For at dykke ned i emnet bør vi introducere dig til et par nye ord og handlinger...

• git repository
• begå
• afdeling
• fusionere
• konflikter
• trække
• skubbe
• hvordan man ignorerer nogle filer (.gitignore)

Og så videre.

Status i Git

Git har flere statuer, der skal forstås og huskes:

• usporet
• modificeret
• iscenesat
• engageret

Hvordan skal du forstå dette?

Disse er statusser, der gælder for filerne, der indeholder vores kode:

1. En fil, der er oprettet, men endnu ikke tilføjet til depotet, har statussen "usporet".
2. Når vi foretager ændringer i filer, der allerede er blevet tilføjet til Git-lageret, så er deres status "modificeret".
3. Blandt de filer, vi har ændret, vælger vi dem, vi har brug for, og disse klasser ændres til "iscenesat" status.
4. En commit oprettes fra forberedte filer i trinvis tilstand og går ind i Git-lageret. Derefter er der ingen filer med status "iscenesat". Men der kan stadig være filer, hvis status er "ændret".

Sådan ser det ud:

Hvad er en forpligtelse?

En commit er hovedbegivenheden, når det kommer til versionskontrol. Den indeholder alle de ændringer, der er foretaget siden forpligtelsen begyndte. Commits er knyttet sammen som en enkelt linket liste. Mere specifikt: Der er en første commit. Når den anden commit er oprettet, ved den, hvad der kommer efter den første. Og på denne måde kan information spores. En commit har også sin egen information, såkaldte metadata:

• forpligtelsens unikke identifikator, som kan bruges til at finde den
• navnet på forpligtelsens forfatter, som oprettede den
• datoen, hvor forpligtelsen blev oprettet
• en kommentar, der beskriver, hvad der blev gjort under commit

Sådan ser det ud:

Hvad er en filial?

En gren er en pegepind til en eller anden forpligtelse. Fordi en commit ved hvilken commit der går forud for den, når en gren peger på en commit, gælder alle de tidligere commits også for den. Derfor kan vi sige, at du kan have så mange filialer, som du vil, der peger på den samme commit. Arbejdet foregår i brancher, så når en ny commit oprettes, flytter grenen sin markør til den nyere commit.

Kom godt i gang med Git

Du kan arbejde med et lokalt lager alene såvel som med et fjerntliggende. For at øve de nødvendige kommandoer kan du begrænse dig til det lokale lager. Den gemmer kun alle projektets oplysninger lokalt i .git-mappen. Hvis vi taler om fjernlageret, så er al information gemt et sted på fjernserveren: kun en kopi af projektet gemmes lokalt. Ændringer i din lokale kopi kan skubbes (git push) til fjernlageret. I vores diskussion her og nedenfor taler vi om at arbejde med Git i konsollen. Selvfølgelig kan du bruge en slags GUI-baseret løsning (for eksempel IntelliJ IDEA), men først bør du finde ud af, hvilke kommandoer der udføres, og hvad de betyder.

Arbejder med Git i et lokalt lager

Dernæst foreslår jeg, at du følger med og udfører alle de trin, jeg gjorde, mens du læste artiklen. Dette vil forbedre din forståelse og beherskelse af materialet. Nå, god appetit! :) For at oprette et lokalt lager skal du skrive:

git init

Dette vil oprette en .git-mappe i konsollens nuværende mappe. .git-mappen gemmer al information om Git-lageret. Slet det ikke ;) Derefter tilføjes filer til projektet, og de tildeles statussen "Usporet". For at kontrollere den aktuelle status for dit arbejde, skriv dette:

git status

Vi er i mestergrenen, og her bliver vi, indtil vi skifter til en anden gren. Dette viser, hvilke filer der er ændret, men endnu ikke er blevet tilføjet til "iscenesat" status. For at tilføje dem til "iscenesat" status, skal du skrive "git add". Vi har et par muligheder her, for eksempel:

• git add -A — tilføj alle filer til "iscenesat" status
• git tilføje. — tilføj alle filer fra denne mappe og alle undermapper. I det væsentlige er dette det samme som det forrige
• git add <filnavn> — tilføjer en specifik fil. Her kan du bruge regulære udtryk til at tilføje filer efter et eller andet mønster. For eksempel, git add *.java: Det betyder, at du kun ønsker at tilføje filer med java-udvidelsen.

De to første muligheder er klart enkle. Tingene bliver mere interessante med den seneste tilføjelse, så lad os skrive:

git add *.txt

For at kontrollere status bruger vi den kommando, vi allerede kender:

git status

Her kan du se, at det regulære udtryk har fungeret korrekt: test_resource.txt har nu status "iscenesat". Og endelig, det sidste trin for at arbejde med et lokalt lager (der er et mere, når du arbejder med fjernlageret ;)) — oprettelse af en ny commit:

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

Dernæst er en fantastisk kommando til at se på forpligtelseshistorien på en filial. Lad os gøre brug af det:

git log

Her kan du se, at vi har oprettet vores første commit, og det inkluderer teksten, som vi leverede på kommandolinjen. Det er meget vigtigt at forstå, at denne tekst skal forklare så præcist som muligt, hvad der blev gjort under denne forpligtelse. Dette vil hjælpe os mange gange i fremtiden. En nysgerrig læser, der endnu ikke er faldet i søvn, kan undre sig over, hvad der skete med GitTest.java-filen. Lad os finde ud af det lige nu. For at gøre dette bruger vi:

git status

Som du kan se, er den stadig "usporet" og venter i kulissen. Men hvad nu hvis vi slet ikke vil tilføje det til projektet? Nogle gange sker det. For at gøre tingene mere interessante, lad os nu prøve at ændre vores test_resource.txt-fil. Lad os tilføje noget tekst der og tjekke status:

git status

Her kan du tydeligt se forskellen mellem "usporet" og "modificeret" status. GitTest.java er "usporet", mens test_resource.txt er "modificeret". Nu hvor vi har filer i den ændrede tilstand, kan vi undersøge ændringerne i dem. Dette kan gøres ved hjælp af følgende kommando:

git diff

Det vil sige, du kan tydeligt se her, hvad jeg tilføjede til vores tekstfil: hej verden! Lad os tilføje vores ændringer til tekstfilen og oprette en commit:

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

For at se på alle commits, skriv:

git log

Som du kan se, har vi nu to commits. Vi tilføjer GitTest.java på samme måde. Ingen kommentarer her, kun kommandoer:

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

Arbejder med .gitignore

Det er klart, at vi kun ønsker at beholde kildekoden alene, og intet andet, i depotet. Så hvad kunne der ellers være? Som minimum kompilerede klasser og/eller filer genereret af udviklingsmiljøer. For at fortælle Git at ignorere dem, skal vi oprette en speciel fil. Gør dette: opret en fil kaldet .gitignore i roden af ​​projektet. Hver linje i denne fil repræsenterer et mønster, der skal ignoreres. I dette eksempel vil .gitignore-filen se sådan ud:

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

Lad os se:

• Den første linje er at ignorere alle filer med filtypenavnet .class
• Den anden linje er at ignorere mappen "mål" og alt, hvad den indeholder
• Den tredje linje er at ignorere alle filer med filtypenavnet .iml
• Den fjerde linje er at ignorere mappen .idea

Lad os prøve at bruge et eksempel. For at se, hvordan det virker, lad os tilføje den kompilerede GitTest.class til projektet og kontrollere projektets status:

git status

Det er klart, at vi ikke på en eller anden måde ved et uheld vil tilføje den kompilerede klasse til projektet (ved hjælp af git add -A). For at gøre dette skal du oprette en .gitignore-fil og tilføje alt, hvad der blev beskrevet tidligere: Lad os nu bruge en commit til at tilføje .gitignore-filen til projektet:

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

Og nu sandhedens øjeblik: vi har en kompileret klasse GitTest.class, der er "usporet", som vi ikke ønskede at tilføje til Git-lageret. Nu skulle vi se virkningerne af .gitignore-filen:

git status

Perfekt! .gitignore +1 :)

Arbejder med grene og sådan

Naturligvis er det ubelejligt at arbejde i én gren for ensomme udviklere, og det er umuligt, når der er mere end én person på et team. Derfor har vi afdelinger. Som jeg sagde tidligere, er en gren kun en bevægelig pegepind til commits. I denne del vil vi udforske arbejdet i forskellige brancher: hvordan man kan flette ændringer fra en gren til en anden, hvilke konflikter der kan opstå og meget mere. For at se en liste over alle grene i depotet og forstå, hvilken du er i, skal du skrive:

git branch -a

Du kan se, at vi kun har én mastergren. Stjernen foran indikerer, at vi er i den. Du kan i øvrigt også bruge kommandoen "git status" til at finde ud af, hvilken gren vi er i. Så er der flere muligheder for at oprette brancher (der kan være flere — det er dem jeg bruger):

• oprette en ny filial baseret på den vi er i (99% af tilfældene)
• oprette en filial baseret på en specifik commit (1 % af tilfældene)

Lad os oprette en filial baseret på en bestemt commit

Vi vil stole på forpligtelsens unikke identifikator. For at finde den skriver vi:

git log

Jeg har fremhævet commit med kommentaren "added hello world..." Dens unikke identifikator er 6c44e53d06228f888f2f454d3cb8c1c976dd73f8. Jeg vil oprette en "udviklings"-gren, der starter fra denne commit. For at gøre dette skriver jeg:

git checkout -b development 6c44e53d06228f888f2f454d3cb8c1c976dd73f8

Der oprettes en filial med kun de to første commits fra mastergrenen. For at bekræfte dette skal vi først sørge for at skifte til en anden filial og se på antallet af commits der:

git status
git log

Og som forventet har vi to commits. Forresten, her er en interessant pointe: der er ingen .gitignore-fil i denne gren endnu, så vores kompilerede fil (GitTest.class) er nu fremhævet med "usporet" status. Nu kan vi gennemgå vores afdelinger igen ved at skrive dette:

git branch -a

Du kan se, at der er to grene: "master" og "udvikling". Vi er i øjeblikket i udvikling.

Lad os oprette en filial baseret på den nuværende

Den anden måde at skabe en gren på er at skabe den fra en anden. Jeg vil oprette en gren baseret på mastergrenen. Først skal jeg skifte til det, og næste skridt er at oprette en ny. Lad os se:

• git checkout master — skift til mastergrenen
• git status — bekræft, at vi faktisk er i master-grenen

Her kan du se, at vi skiftede til mastergrenen, .gitignore-filen er i kraft, og den kompilerede klasse er ikke længere fremhævet som "usporet". Nu opretter vi en ny filial baseret på mastergrenen:

git checkout -b feature/update-txt-files

Hvis du er usikker på, om denne gren er det samme som "master", kan du nemt tjekke ved at udføre "git log" og se på alle commits. Der skulle være fire af dem.

Konfliktløsning

Før vi udforsker, hvad en konflikt er, skal vi tale om at flette en gren ind i en anden. Dette billede viser processen med at fusionere en gren til en anden: Her har vi en hovedgren. På et tidspunkt oprettes en sekundær gren ud fra hovedgrenen og ændres derefter. Når arbejdet er færdigt, skal vi flette den ene gren ind i den anden. Jeg vil ikke beskrive de forskellige funktioner: I denne artikel ønsker jeg kun at formidle en generel forståelse. Hvis du har brug for detaljerne, kan du selv slå dem op. I vores eksempel oprettede vi grenen feature/update-txt-files. Som det fremgår af filialens navn, opdaterer vi teksten. Nu skal vi oprette en ny commit for dette arbejde:

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

Hvis vi nu ønsker at flette grenen feature/update-txt-files til master, skal vi gå til master og skrive "git merge feature/update-txt-filer":

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

Som et resultat inkluderer mastergrenen nu også den commit, der blev tilføjet til feature/update-txt-filer. Denne funktionalitet blev tilføjet, så du kan slette en funktionsgren. For at gøre dette skriver vi:

git branch -D feature/update-txt-files

Alt er klart indtil videre, ja? Lad os komplicere situationen: lad os nu sige, at du skal ændre txt-filen igen. Men nu vil denne fil også blive ændret i mastergrenen. Det vil med andre ord ændre sig parallelt. Git vil ikke være i stand til at finde ud af, hvad vi skal gøre, når vi vil flette vores nye kode ind i mastergrenen. Lad os gå! Vi opretter en ny filial baseret på master, foretager ændringer til text_resource.txt og opretter en commit til dette arbejde:

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

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

Gå til mastergrenen og opdater også denne tekstfil på samme linje som i featuregrenen:

git checkout master
… we updated test_resource.txt

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

Og nu det mest interessante punkt: vi skal flette ændringer fra feature/add-header-grenen til master. Vi er i mastergrenen, så vi behøver kun at skrive:

git merge feature/add-header

Men resultatet vil være en konflikt i filen test_resource.txt: Her kan vi se, at Git ikke selv kunne bestemme, hvordan denne kode skulle flettes. Det fortæller os, at vi først skal løse konflikten og først derefter udføre forpligtelsen. OKAY. Vi åbner filen med konflikten i en teksteditor og ser: For at forstå, hvad Git gjorde her, skal vi huske, hvilke ændringer vi lavede og hvor, og derefter sammenligne:

1. Ændringerne, der var på denne linje i mastergrenen, findes mellem "<<<<<<< HEAD" og "========".
2. Ændringerne der var i feature/add-header grenen findes mellem "=======" og ">>>>>>> feature/add-header”.

Det er sådan, Git fortæller os, at den ikke kunne finde ud af, hvordan man udfører fletningen på denne placering i filen. Den delte dette afsnit i to dele fra de forskellige grene og inviterer os til selv at løse fusionskonflikten. Fair nok. Jeg beslutter dristigt at fjerne alt og efterlader kun ordet "header": Lad os se på status for ændringerne. Beskrivelsen vil være lidt anderledes. I stedet for en "modificeret" status har vi "unfusion". Så kunne vi have nævnt en femte status? Jeg tror ikke, det er nødvendigt. Lad os se:

git status

Vi kan overbevise os selv om, at dette er et særligt, usædvanligt tilfælde. Lad os fortsætte:

git add *.txt

Du bemærker måske, at beskrivelsen foreslår kun at skrive "git commit". Lad os prøve at skrive det:

git commit

Og bare sådan gjorde vi det - vi løste konflikten i konsollen. Dette kan selvfølgelig gøres lidt lettere i integrerede udviklingsmiljøer. For eksempel i IntelliJ IDEA er alt sat så godt op, at du kan udføre alle de nødvendige handlinger lige i det. Men IDE'er gør mange ting "under motorhjelmen", og vi forstår ofte ikke, hvad der præcist sker der. Og når der ikke er forståelse, kan der opstå problemer.

Arbejde med fjerndepoter

Det sidste trin er at finde ud af et par flere kommandoer, der er nødvendige for at arbejde med fjernlageret. Som sagt er et fjernlager et sted, hvor depotet er gemt, og hvorfra du kan klone det. Hvilken slags fjerndepoter er der? Eksempler:

• GitHub er den største lagerplatform for repositories og kollaborativ udvikling. Jeg har allerede beskrevet det i tidligere artikler.
  Følg mig på GitHub . Jeg viser ofte mit arbejde frem i de områder, hvor jeg studerer til arbejde.

• GitLab er et webbaseret værktøj til DevOps- livscyklussen med open source . Det er et Git -baseret system til styring af kodelagre med sin egen wiki, fejlsporingssystem , CI/CD-pipeline og andre funktioner.
  Efter nyheden om, at Microsoft købte GitHub, duplikerede nogle udviklere deres projekter i GitLab.

• BitBucket er en webservice til projekthosting og samarbejdsudvikling baseret på Mercurial og Git versionskontrolsystemerne. På et tidspunkt havde det en stor fordel i forhold til GitHub, idet det tilbød gratis private repositories. Sidste år introducerede GitHub også denne funktion til alle gratis.

• Og så videre…

Når du arbejder med et fjernlager, er den første ting at gøre at klone projektet til dit lokale lager. Til dette eksporterede jeg projektet, som vi lavede lokalt, og nu kan alle klone det for sig selv ved at skrive:

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

Der er nu en komplet lokal kopi af projektet. For at være sikker på, at den lokale kopi af projektet er den nyeste, skal du trække projektet ved at skrive:

git pull

I vores tilfælde er intet i fjernlageret ændret på nuværende tidspunkt, så svaret er: Allerede opdateret. Men hvis jeg foretager ændringer i fjernlageret, opdateres det lokale, efter at vi trækker dem. Og endelig er den sidste kommando at skubbe dataene til fjernlageret. Når vi har gjort noget lokalt og vil sende det til fjernlageret, skal vi først oprette en ny commit lokalt. For at demonstrere dette, lad os tilføje noget andet til vores tekstfil: Nu er noget helt almindeligt for os - vi opretter en commit for dette arbejde:

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

Kommandoen til at skubbe dette til fjernlageret er:

git push

Nå, det var alt, jeg ville sige. Tak for din opmærksomhed. Følg mig på GitHub , hvor jeg poster forskellige fede eksempelprojekter relateret til mit personlige studie og arbejde.

Nyttigt link

• Officiel Git-dokumentation . Jeg anbefaler det som reference.