I stedet for en introduktion
Hej! I dag skal vi tale om et versionskontrolsystem, nemlig Git.
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:

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)
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:- En fil, der er oprettet, men endnu ikke tilføjet til depotet, har statussen "usporet".
- Når vi foretager ændringer i filer, der allerede er blevet tilføjet til Git-lageret, så er deres status "modificeret".
- Blandt de filer, vi har ændret, vælger vi dem, vi har brug for, og disse klasser ændres til "iscenesat" status.
- 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".

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

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

git status

- 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.
git add *.txt
For at kontrollere status bruger vi den kommando, vi allerede kender:
git status

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

git log

git status

git status

git diff

git add test_resource.txt
git commit -m "added hello word! to test_resource.txt"
For at se på alle commits, skriv:
git log

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
git status


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

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

- 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

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

git branch -a

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

git checkout -b feature/update-txt-files

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:

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

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

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"

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: 

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

git status

git add *.txt

git commit

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…
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


git add test_resource.txt
git commit -m "prepared txt for pushing"
Kommandoen til at skubbe dette til fjernlageret er:
git push

Nyttigt link
- Officiel Git-dokumentation . Jeg anbefaler det som reference.
GO TO FULL VERSION