Aan de slag met Git: een uitgebreide gids voor nieuwkomers

In plaats van een inleiding

Hallo! Vandaag gaan we het hebben over een versiebeheersysteem, namelijk Git. Je hebt niets met programmeren te maken als je Git niet kent/begrijpt. Maar het mooie is dat je niet alle Git-commando's en -functies in je hoofd hoeft te houden om continu in dienst te zijn. U moet een reeks commando's kennen die u zullen helpen alles te begrijpen wat er gebeurt.

Git-basis

Git is een gedistribueerd versiebeheersysteem voor onze code. Waarom hebben we het nodig? Gedistribueerde teams hebben een soort systeem nodig om hun werk te beheren. Het is nodig om veranderingen bij te houden die zich in de loop van de tijd voordoen. Dat wil zeggen, we moeten stap voor stap kunnen zien welke bestanden zijn gewijzigd en hoe. Dit is vooral belangrijk wanneer u onderzoekt wat er is veranderd in de context van een enkele taak, waardoor het mogelijk wordt om de wijzigingen ongedaan te maken.

Git installeren

Laten we Java op uw computer installeren.

Installeren op Windows

Zoals gewoonlijk moet u een exe-bestand downloaden en uitvoeren. Alles is hier eenvoudig: klik op de eerste Google-link , voer de installatie uit en dat is alles. Om dit te doen, gebruiken we de bash-console van Windows. Op Windows moet je Git Bash uitvoeren. Zo ziet het eruit in het menu Start: Dit is nu een opdrachtprompt waarmee u kunt werken. Om te voorkomen dat je elke keer naar de map met het project moet gaan om Git daar te openen, kun je met de rechtermuisknop de opdrachtprompt in de projectmap openen met het pad dat we nodig hebben:

Installeren op Linux

Gewoonlijk maakt Git deel uit van Linux-distributies en is het al geïnstalleerd, omdat het een tool is die oorspronkelijk is geschreven voor de ontwikkeling van de Linux-kernel. Maar er zijn situaties waarin dat niet zo is. Om dit te controleren, moet je een terminal openen en schrijven: git --version. Krijg je een verstaanbaar antwoord, dan hoef je niets te installeren. Open een terminal en installeer Git op Ubuntu . Ik werk aan Ubuntu, dus ik kan je vertellen wat je ervoor moet schrijven: sudo apt-get install git.

Installeren op macOS

Ook hier moet je eerst controleren of Git er al is. Als je het niet hebt, kun je het het gemakkelijkst downloaden door hier de nieuwste versie te downloaden . Als Xcode is geïnstalleerd, wordt Git zeker automatisch geïnstalleerd.

Git-instellingen

Git heeft gebruikersinstellingen voor de gebruiker die werk zal inleveren. Dit is logisch en noodzakelijk, omdat Git deze informatie gebruikt voor het veld Auteur wanneer een commit wordt gemaakt. Stel een gebruikersnaam en wachtwoord in voor al uw projecten door de volgende opdrachten uit te voeren:

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

Als u de auteur voor een specifiek project moet wijzigen, kunt u "--global" verwijderen. Dit levert ons het volgende op:

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

Een stukje theorie...

Om in het onderwerp te duiken, moeten we u kennis laten maken met een paar nieuwe woorden en acties...

• git-opslagplaats
• verbinden
• tak
• samenvoegen
• conflicten
• trekken
• duw
• hoe sommige bestanden te negeren (.gitignore)

Enzovoort.

Statussen in Git

Git heeft verschillende standbeelden die begrepen en onthouden moeten worden:

• niet gevolgd
• gewijzigd
• geënsceneerd
• betrokken

Hoe moet je dit begrijpen?

Dit zijn statussen die van toepassing zijn op de bestanden die onze code bevatten:

1. Een bestand dat is aangemaakt maar nog niet is toegevoegd aan de repository heeft de status "untracked".
2. Wanneer we wijzigingen aanbrengen in bestanden die al aan de Git-repository zijn toegevoegd, is hun status "gewijzigd".
3. Onder de bestanden die we hebben gewijzigd, selecteren we de bestanden die we nodig hebben, en deze klassen worden gewijzigd in de status "geënsceneerd".
4. Er wordt een commit gemaakt van voorbereide bestanden in de geënsceneerde staat en gaat naar de Git-repository. Daarna zijn er geen bestanden meer met de status "staged". Maar er kunnen nog steeds bestanden zijn waarvan de status "gewijzigd" is.

Hier is hoe het eruit ziet:

Wat is een verbintenis?

Een commit is de belangrijkste gebeurtenis als het gaat om versiebeheer. Het bevat alle wijzigingen die zijn aangebracht sinds het begin van de commit. Commits zijn aan elkaar gekoppeld als een enkelvoudig gekoppelde lijst. Meer specifiek: er is een eerste commit. Wanneer de tweede commit is gemaakt, weet deze wat er na de eerste komt. En op deze manier kan informatie worden gevolgd. Een commit heeft ook zijn eigen informatie, zogenaamde metadata:

• de unieke identificatie van de commit, die kan worden gebruikt om deze te vinden
• de naam van de auteur van de commit, die deze heeft gemaakt
• de datum waarop de commit is gemaakt
• een opmerking die beschrijft wat er tijdens de commit is gedaan

Zo ziet het eruit:

Wat is een filiaal?

Een branch is een pointer naar een bepaalde commit. Omdat een commit weet welke commit eraan voorafgaat, als een branch naar een commit verwijst, zijn al die eerdere commits ook daarop van toepassing. Dienovereenkomstig zouden we kunnen zeggen dat je zoveel branches kunt hebben als je wilt die naar dezelfde commit verwijzen. Het werk gebeurt in branches, dus wanneer een nieuwe commit wordt gemaakt, verplaatst de branch zijn pointer naar de meer recente commit.

Aan de slag met Git

U kunt zowel alleen met een lokale repository als met een externe repository werken. Om de vereiste commando's te oefenen, kunt u zich beperken tot de lokale repository. Het slaat alleen alle projectinformatie lokaal op in de .git-map. Als we het hebben over de externe repository, dan wordt alle informatie ergens op de externe server opgeslagen: alleen een kopie van het project wordt lokaal opgeslagen. Wijzigingen in uw lokale kopie kunnen worden gepusht (git push) naar de externe repository. In onze discussie hier en hieronder hebben we het over werken met Git in de console. U kunt natuurlijk een soort GUI-gebaseerde oplossing gebruiken (bijvoorbeeld IntelliJ IDEA), maar eerst moet u uitzoeken welke opdrachten worden uitgevoerd en wat ze betekenen.

Werken met Git in een lokale repository

Vervolgens stel ik voor dat u meegaat en alle stappen uitvoert die ik deed toen u het artikel las. Dit zal uw begrip en beheersing van de stof verbeteren. Nou, eet smakelijk! :) Om een ​​lokale repository te maken, moet je schrijven:

git init

Hierdoor wordt een .git-map gemaakt in de huidige map van de console. In de .git-map wordt alle informatie over de Git-repository opgeslagen. Niet verwijderen ;) Vervolgens worden bestanden aan het project toegevoegd en krijgen ze de status "Niet gevolgd". Schrijf dit om de huidige status van uw werk te controleren:

git status

We zitten in de master branch en hier blijven we totdat we overschakelen naar een andere branch. Hierin wordt weergegeven welke bestanden zijn gewijzigd maar nog niet zijn toegevoegd aan de status "staged". Om ze toe te voegen aan de "staged" status, moet je "git add" schrijven. We hebben hier een paar opties, bijvoorbeeld:

• git add -A — voeg alle bestanden toe aan de status "staged".
• git toevoegen. — voeg alle bestanden uit deze map en alle submappen toe. In wezen is dit hetzelfde als de vorige
• git add <bestandsnaam> — voegt een specifiek bestand toe. Hier kunt u reguliere expressies gebruiken om bestanden volgens een bepaald patroon toe te voegen. Bijvoorbeeld git add *.java: Dit betekent dat je alleen bestanden met de java-extensie wilt toevoegen.

De eerste twee opties zijn duidelijk eenvoudig. Dingen worden interessanter met de nieuwste toevoeging, dus laten we schrijven:

git add *.txt

Om de status te controleren gebruiken we het reeds bekende commando:

git status

Hier kun je zien dat de reguliere expressie correct heeft gewerkt: test_resource.txt heeft nu de status "staged". En tot slot, de laatste fase voor het werken met een lokale repository (er is er nog een bij het werken met de externe repository;)) — een nieuwe commit maken:

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

Het volgende is een geweldig commando om naar de commit-geschiedenis van een branch te kijken. Laten we er gebruik van maken:

git log

Hier kun je zien dat we onze eerste commit hebben gemaakt en deze bevat de tekst die we op de opdrachtregel hebben opgegeven. Het is erg belangrijk om te begrijpen dat deze tekst zo nauwkeurig mogelijk moet uitleggen wat er tijdens deze commit is gedaan. Dit zal ons in de toekomst nog vaak helpen. Een nieuwsgierige lezer die nog niet in slaap is gevallen, vraagt ​​zich misschien af ​​wat er met het GitTest.java-bestand is gebeurd. Laten we het nu uitzoeken. Hiervoor gebruiken we:

git status

Zoals je kunt zien, is het nog steeds "untracked" en wacht het in de coulissen. Maar wat als we het helemaal niet aan het project willen toevoegen? Soms gebeurt dat. Laten we, om het interessanter te maken, nu proberen ons test_resource.txt-bestand te wijzigen. Laten we daar wat tekst toevoegen en de status controleren:

git status

Hier kunt u duidelijk het verschil zien tussen de status "niet gevolgd" en "gewijzigd". GitTest.java is "niet gevolgd", terwijl test_resource.txt "gewijzigd" is. Nu we bestanden in de gewijzigde staat hebben, kunnen we de aangebrachte wijzigingen bekijken. Dit kan worden gedaan met behulp van de volgende opdracht:

git diff

Dat wil zeggen, je kunt hier duidelijk zien wat ik aan ons tekstbestand heb toegevoegd: hallo wereld! Laten we onze wijzigingen aan het tekstbestand toevoegen en een commit maken:

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

Om alle commits te bekijken, schrijf je:

git log

Zoals je kunt zien, hebben we nu twee commits. We zullen GitTest.java op dezelfde manier toevoegen. Geen opmerkingen hier, alleen commando's:

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

Werken met .gitignore

Het is duidelijk dat we alleen de broncode willen behouden, en niets anders, in de repository. Dus wat kan er nog meer zijn? Minimaal gecompileerde klassen en/of bestanden gegenereerd door ontwikkelomgevingen. Om Git te vertellen ze te negeren, moeten we een speciaal bestand maken. Doe dit: maak een bestand aan met de naam .gitignore in de hoofdmap van het project. Elke regel in dit bestand vertegenwoordigt een te negeren patroon. In dit voorbeeld ziet het .gitignore-bestand er als volgt uit:

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

Laten we kijken:

• De eerste regel is om alle bestanden met de extensie .class te negeren
• De tweede regel is om de map "target" en alles wat deze bevat te negeren
• De derde regel is om alle bestanden met de extensie .iml te negeren
• De vierde regel is om de map .idea te negeren

Laten we proberen een voorbeeld te gebruiken. Om te zien hoe het werkt, voegen we de gecompileerde GitTest.class toe aan het project en controleren we de projectstatus:

git status

Het is duidelijk dat we op de een of andere manier niet per ongeluk de gecompileerde klasse aan het project willen toevoegen (met behulp van git add -A). Maak hiervoor een .gitignore-bestand aan en voeg alles toe wat eerder is beschreven: Laten we nu een commit gebruiken om het .gitignore-bestand aan het project toe te voegen:

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

En nu het moment van de waarheid: we hebben een gecompileerde klasse GitTest.class die "untracked" is, die we niet wilden toevoegen aan de Git-repository. Nu zouden we de effecten van het .gitignore-bestand moeten zien:

git status

Perfect! .gitignore +1 :)

Werken met takken en zo

Natuurlijk is werken in slechts één branche onhandig voor solitaire ontwikkelaars, en het is onmogelijk als er meer dan één persoon in een team zit. Daarom hebben we vestigingen. Zoals ik al eerder zei, is een branch slechts een verplaatsbare pointer naar commits. In dit deel gaan we in op het werken in verschillende branches: hoe veranderingen van de ene branch in de andere kunnen worden samengevoegd, welke conflicten er kunnen ontstaan, en nog veel meer. Om een ​​lijst te zien van alle branches in de repository en te begrijpen in welke je bent, moet je schrijven:

git branch -a

Je kunt zien dat we maar één master branch hebben. Het sterretje ervoor geeft aan dat we erin zitten. Trouwens, je kunt ook het "git status" commando gebruiken om uit te vinden in welke branch we zitten. Dan zijn er verschillende opties om branches te maken (misschien zijn er meer - dit zijn degenen die ik gebruik):

• maak een nieuwe branche op basis van degene waarin we ons bevinden (99% van de gevallen)
• maak een branch op basis van een specifieke commit (1% van de gevallen)

Laten we een branch maken op basis van een specifieke commit

We vertrouwen op de unieke identificatie van de commit. Om het te vinden, schrijven we:

git log

Ik heb de commit gemarkeerd met de opmerking "hello world toegevoegd..." De unieke identifier is 6c44e53d06228f888f2f454d3cb8c1c976dd73f8. Ik wil een "ontwikkeling" -tak maken die begint met deze commit. Om dit te doen, schrijf ik:

git checkout -b development 6c44e53d06228f888f2f454d3cb8c1c976dd73f8

Een branch wordt gemaakt met alleen de eerste twee commits van de master branch. Om dit te verifiëren, zorgen we er eerst voor dat we overschakelen naar een andere branch en kijken naar het aantal commits daar:

git status
git log

En zoals verwacht hebben we twee commits. Trouwens, hier is een interessant punt: er is nog geen .gitignore-bestand in deze branch, dus ons gecompileerde bestand (GitTest.class) is nu gemarkeerd met de status "untracked". Nu kunnen we onze vestigingen opnieuw beoordelen door dit te schrijven:

git branch -a

Je ziet dat er twee takken zijn: "meester" en "ontwikkeling". We zijn momenteel in ontwikkeling.

Laten we een branch maken op basis van de huidige

De tweede manier om een ​​branch te maken, is door deze vanuit een andere te maken. Ik wil een branch maken op basis van de master branch. Eerst moet ik ernaar overschakelen en de volgende stap is het maken van een nieuwe. Laten we kijken:

• git checkout master — schakel over naar de master branch
• git status — verifieer dat we ons daadwerkelijk in de master branch bevinden

Hier kun je zien dat we zijn overgeschakeld naar de master-branch, het .gitignore-bestand is actief en de gecompileerde klasse is niet langer gemarkeerd als "untracked". Nu maken we een nieuwe branch op basis van de master branch:

git checkout -b feature/update-txt-files

Als je niet zeker weet of deze branch hetzelfde is als "master", kun je dit eenvoudig controleren door "git log" uit te voeren en alle commits te bekijken. Het zouden er vier moeten zijn.

Conflictoplossing

Voordat we onderzoeken wat een conflict is, moeten we het hebben over het samenvoegen van de ene tak in de andere. Deze afbeelding toont het proces van het samenvoegen van de ene tak in de andere: Hier hebben we een hoofdtak. Op een gegeven moment wordt een secundaire tak gemaakt buiten de hoofdtak en vervolgens aangepast. Zodra het werk is gedaan, moeten we de ene tak in de andere samenvoegen. Ik zal de verschillende kenmerken niet beschrijven: in dit artikel wil ik alleen een algemeen begrip overbrengen. Als u de gegevens nodig heeft, kunt u deze zelf opzoeken. In ons voorbeeld hebben we de branch feature/update-txt-files gemaakt. Zoals aangegeven door de naam van het filiaal, werken we de tekst bij. Nu moeten we een nieuwe commit maken voor dit werk:

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

Als we nu de feature/update-txt-files branch in master willen samenvoegen, moeten we naar master gaan en "git merge feature/update-txt-files" schrijven:

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

Het resultaat is dat de master branch nu ook de commit bevat die is toegevoegd aan feature/update-txt-bestanden. Deze functionaliteit is toegevoegd, dus je kunt een feature branch verwijderen. Om dit te doen, schrijven we:

git branch -D feature/update-txt-files

Alles is tot nu toe duidelijk, ja? Laten we de situatie ingewikkelder maken: laten we nu zeggen dat u het txt-bestand opnieuw moet wijzigen. Maar nu zal dit bestand ook in de master branch worden gewijzigd. Met andere woorden, het zal parallel veranderen. Git zal niet kunnen achterhalen wat te doen als we onze nieuwe code willen samenvoegen in de master branch. Laten we gaan! We zullen een nieuwe branch maken op basis van master, wijzigingen aanbrengen in text_resource.txt en een commit maken voor dit werk:

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

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

Ga naar de master branch en update ook dit tekstbestand op dezelfde regel als in de feature branch:

git checkout master
… we updated test_resource.txt

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

En nu het meest interessante punt: we moeten wijzigingen van de feature/add-header branch samenvoegen tot master. We zitten in de master branch, dus we hoeven alleen maar te schrijven:

git merge feature/add-header

Maar het resultaat zal een conflict zijn in het bestand test_resource.txt: Hier kunnen we zien dat Git niet zelf kan beslissen hoe deze code moet worden samengevoegd. Het vertelt ons dat we eerst het conflict moeten oplossen en pas daarna de commit uitvoeren. OK. We openen het bestand met het conflict in een teksteditor en zien: Om te begrijpen wat Git hier heeft gedaan, moeten we onthouden welke wijzigingen we hebben aangebracht en waar, en dan vergelijken:

1. De veranderingen op deze regel in de master branch zijn gevonden tussen "<<<<<<< HEAD" en "=======".
2. De wijzigingen in de feature/add-header branch zijn gevonden tussen "=======" en ">>>>>>> feature/add-header".

Dit is hoe Git ons vertelt dat het niet kon achterhalen hoe de samenvoeging op deze locatie in het bestand moest worden uitgevoerd. Het verdeelde deze sectie in twee delen van de verschillende takken en nodigde ons uit om het samenvoegconflict zelf op te lossen. Redelijk. Ik besluit moedig om alles te verwijderen en alleen het woord "header" over te laten: Laten we eens kijken naar de status van de wijzigingen. De beschrijving zal iets anders zijn. In plaats van een "gewijzigde" status hebben we "unmerged". Hadden we dus een vijfde status kunnen noemen? Ik denk niet dat dit nodig is. Laten we eens kijken:

git status

We kunnen onszelf ervan overtuigen dat dit een bijzonder, ongewoon geval is. Laten we doorgaan:

git add *.txt

Het is je misschien opgevallen dat de beschrijving suggereert om alleen "git commit" te schrijven. Laten we proberen dat te schrijven:

git commit

En zomaar, we hebben het gedaan - we hebben het conflict in de console opgelost. In geïntegreerde ontwikkelomgevingen kan dat natuurlijk wat makkelijker. In IntelliJ IDEA is bijvoorbeeld alles zo goed ingesteld dat je alle benodigde handelingen er direct in kunt uitvoeren. Maar IDE's doen veel dingen "onder de motorkap", en we begrijpen vaak niet wat daar precies gebeurt. En als er geen begrip is, kunnen er problemen ontstaan.

Werken met externe opslagplaatsen

De laatste stap is om nog een paar commando's te bedenken die nodig zijn om met de externe repository te werken. Zoals ik al zei, een externe repository is een plaats waar de repository is opgeslagen en van waaruit u deze kunt klonen. Wat voor soort externe opslagplaatsen zijn er? Voorbeelden:

• GitHub is het grootste opslagplatform voor opslagplaatsen en gezamenlijke ontwikkeling. Ik heb het al beschreven in eerdere artikelen.
  Volg mij op GitHub . Ik pronk daar vaak met mijn werk in de gebieden die ik studeer voor werk.

• GitLab is een webgebaseerde tool voor de DevOps- levenscyclus met open source . Het is een op Git gebaseerd systeem voor het beheren van coderepository's met een eigen wiki, bugvolgsysteem , CI/CD-pijplijn en andere functies.
  Na het nieuws dat Microsoft GitHub had gekocht, dupliceerden sommige ontwikkelaars hun projecten in GitLab.

• BitBucket is een webservice voor projecthosting en gezamenlijke ontwikkeling op basis van de versiebeheersystemen Mercurial en Git. Ooit had het een groot voordeel ten opzichte van GitHub omdat het gratis privérepository's aanbood. Vorig jaar introduceerde GitHub deze mogelijkheid ook gratis voor iedereen.

• Enzovoorts…

Wanneer u met een externe repository werkt, is het eerste wat u moet doen het project naar uw lokale repository klonen. Hiervoor heb ik het project geëxporteerd dat we lokaal hebben gemaakt, en nu kan iedereen het voor zichzelf klonen door te schrijven:

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

Er is nu een volledige lokale kopie van het project. Om er zeker van te zijn dat de lokale kopie van het project de nieuwste is, moet u het project ophalen door te schrijven:

git pull

In ons geval is er op dit moment niets veranderd in de externe repository, dus het antwoord is: Al up-to-date. Maar als ik wijzigingen aanbreng in de externe repository, wordt de lokale geüpdatet nadat we ze hebben opgehaald. En tot slot is de laatste opdracht om de gegevens naar de externe repository te pushen. Als we lokaal iets hebben gedaan en dit naar de remote repository willen sturen, moeten we eerst lokaal een nieuwe commit maken. Laten we, om dit te demonstreren, iets anders aan ons tekstbestand toevoegen: Nu iets heel gewoons voor ons — we maken een commit voor dit werk:

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

De opdracht om dit naar de externe repository te pushen is:

git push

Nou, dat is alles wat ik wilde zeggen. Bedankt voor uw aandacht. Volg mij op GitHub , waar ik verschillende coole voorbeeldprojecten plaats die verband houden met mijn persoonlijke studie en werk.

Handige link

• Officiële Git-documentatie . Ik raad het aan als referentie.