1. Een gedetailleerde gids voor Git voor beginners

Vandaag gaan we het hebben over een versiebeheersysteem, namelijk Git.

Je kunt echt geen volwaardige programmeur zijn zonder deze tool te kennen en te begrijpen. Natuurlijk hoef je niet alle Git-commando's en -functies in je hoofd 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? 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.

Laten we ons de volgende situatie voorstellen: we hebben werkende code, alles erin is goed, maar dan besluiten we om iets te verbeteren of aan te passen. Geen probleem, maar onze "verbetering" brak de helft van de functies van het programma en maakte het onmogelijk om te werken. Dus wat nu? Zonder Git zou je uren moeten zitten nadenken en je proberen te herinneren hoe alles oorspronkelijk was. Maar met Git draaien we de commit gewoon terug — en dat is alles.

Of wat als er twee ontwikkelaars tegelijkertijd hun eigen codewijzigingen doorvoeren? Zonder Git kopiëren ze de originele codebestanden en passen ze afzonderlijk aan. Er komt een moment dat beiden hun wijzigingen aan de hoofddirectory willen toevoegen. Wat doe je in dit geval?

Er zullen geen dergelijke problemen zijn als je Git gebruikt.

Git installeren

Laten we Java op uw computer installeren Dit proces verschilt enigszins voor verschillende besturingssystemen.

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 startmenu:

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 de opdrachtprompt in de projectmap openen met de rechtermuisknop 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. Voor Ubuntu moet je schrijven: sudo apt-get install git. En dat is alles: nu kunt u Git in elke terminal gebruiken.

Installeren op macOS

Ook hier moet je eerst controleren of Git er al is (zie hierboven, idem als op Linux).

Als u deze niet hebt, kunt u deze het gemakkelijkst downloaden door 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:

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

Een stukje theorie

Om in het onderwerp te duiken, moeten we u kennis laten maken met een paar nieuwe woorden en daden... Anders is er niets om over te praten. Dit is natuurlijk jargon dat vanuit het Engels tot ons komt, dus ik zal vertalingen tussen haakjes toevoegen.

Welke woorden en daden?

• 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. Met andere woorden, hun levenscyclus ziet er meestal zo uit:

• Een bestand dat is aangemaakt maar nog niet is toegevoegd aan de repository heeft de status "untracked".
• Wanneer we wijzigingen aanbrengen in bestanden die al aan de Git-repository zijn toegevoegd, is hun status "gewijzigd".
• Onder de bestanden die we hebben gewijzigd, selecteren we degene die we nodig hebben (we hebben bijvoorbeeld geen gecompileerde klassen nodig), en deze klassen worden gewijzigd in de status "geënsceneerd".
• Een commit wordt 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.

Zo ziet het eruit:

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.

Concreet is er een eerste commit. Wanneer de tweede commit is gemaakt, weet deze (de tweede) 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 het 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

Om een ​​lokale repository te maken, moet u het volgende schrijven:

Hierdoor wordt een verborgen .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:

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 hetzelfde als de vorige;
• git add <file name> — 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:

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

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:

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

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:

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:

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 onderzoeken. Dit kan worden gedaan met behulp van de volgende opdracht:

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:

Om alle commits te bekijken, schrijf je:

Zoals je kunt zien, hebben we nu twee commits.

We zullen GitTest.java op dezelfde manier toevoegen. Geen opmerkingen hier, alleen commando's:

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:

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:

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 en voeg alles toe wat eerder is beschreven:

Laten we nu een commit gebruiken om het .gitignore-bestand aan het project toe te voegen:

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:

Perfect! .gitignore +1 :)

Werken met takken

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.

Een branch is slechts een verplaatsbare pointer naar commits.

In dit deel onderzoeken we 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:

Je kunt zien dat we maar één master branch hebben. Het sterretje ervoor geeft aan dat we erin zitten. Je kunt trouwens ook het "git status" commando gebruiken om uit te zoeken in welke branch we zitten.

Dan zijn er verschillende opties om branches te maken (er kunnen er meer zijn - dit zijn degene 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:

We hebben de commit gemarkeerd met de opmerking "hello world toegevoegd..." De unieke identifier is 6c44e53d06228f888f2f454d3cb8c1c976dd73f8. We willen een "ontwikkelings" branch creëren die begint vanaf deze commit. Om dit te doen, schrijven we:

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:

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:

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. We willen een branch maken op basis van de master branch. Eerst moeten we 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 van kracht en de gecompileerde klasse is niet langer gemarkeerd als "untracked".

Nu maken we een nieuwe branch op basis van de master branch:

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 hoofdvestiging. Op een gegeven moment wordt er een secundaire tak gemaakt buiten de hoofdtak en vervolgens aangepast. Zodra het werk is gedaan, moeten we de ene tak in de andere samenvoegen.

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:

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:

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:

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.

We zullen een nieuwe branch maken op basis van master, wijzigingen aanbrengen in text_resource.txt en een commit maken voor dit werk:

... we wijzigingen aanbrengen in het bestand

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

… we hebben test_resource.txt bijgewerkt

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:

Maar het resultaat is een conflict in het bestand test_resource.txt:

Hier kunnen we zien dat Git niet zelf kon beslissen hoe deze code samen te voegen. 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:

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

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

En zo hebben we 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.
• 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.
• 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 hebben we het project dat we lokaal hebben gemaakt geëxporteerd. Nu kan iedereen het voor zichzelf klonen door te schrijven:

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:

In ons geval is er op dit moment niets veranderd in de externe repository, dus het antwoord is: Al up-to-date.

Maar als we wijzigingen aanbrengen 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. Om dit te demonstreren, voegen we iets anders toe aan ons tekstbestand:

Nu iets heel gewoons voor ons — we creëren een commit voor dit werk:

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

Dat is het voor nu!

2. Werken met Git in IntelliJ IDEA

In dit deel leer je werken met Git in IntelliJ IDEA.

Vereiste invoer:

1. Lees, volg mee en begrijp het vorige deel. Dit zal helpen ervoor te zorgen dat alles is ingesteld en klaar is voor gebruik.
2. Installeer IntelliJ IDEA. Hier zou alles in orde moeten zijn :)
3. Wijs een uur toe om volledig meesterschap te bereiken.

Laten we werken met het demoproject dat ik heb gebruikt voor het artikel over Git.

Kloon het project lokaal

Er zijn hier twee opties:

1. Als je al een GitHub-account hebt en later iets wilt pushen, is het beter om het project te splitsen en je eigen exemplaar te klonen. Hoe je een fork maakt, lees je in een ander artikel onder het kopje Een voorbeeld van de forking workflow .
2. Kloon de repository en doe alles lokaal zonder de mogelijkheid om alles naar de server te pushen.

Om een ​​project van GitHub te klonen, moet u de projectlink kopiëren en doorgeven aan IntelliJ IDEA:

1. Kopieer het projectadres:

2. Open IntelliJ IDEA en selecteer "Get from Version Control":

3. Kopieer en plak het projectadres:

4. U wordt gevraagd om een ​​IntelliJ IDEA-project te maken. Accepteer het aanbod:

5. Aangezien er geen bouwsysteem is, selecteren we "Project maken van bestaande bronnen":

6. Vervolgens zie je dit prachtige scherm:

Nu we het klonen door hebben, kun je eens rondkijken.

Eerste blik op IntelliJ IDEA als Git UI

Bekijk het gekloonde project eens nader: u kunt al veel informatie krijgen over het versiebeheersysteem.

Ten eerste hebben we het deelvenster Versiebeheer in de linkerbenedenhoek. Hier kun je alle lokale wijzigingen vinden en een lijst met commits krijgen (analoog aan "git log").

Laten we verder gaan met een bespreking van Log. Er is een bepaalde visualisatie die ons helpt om precies te begrijpen hoe de ontwikkeling is verlopen. Je kunt bijvoorbeeld zien dat er een nieuwe branch is gemaakt met een toegevoegde header voor txt commit, die vervolgens is samengevoegd in de master branch. Als je op een commit klikt, zie je in de rechterhoek alle informatie over de commit: alle wijzigingen en metadata.

Bovendien kunt u de daadwerkelijke wijzigingen zien. We zien ook dat daar een conflict is opgelost. IDEA presenteert dit ook heel goed.

Als je dubbelklikt op het bestand dat tijdens deze commit is gewijzigd, zullen we zien hoe het conflict is opgelost:

We merken op dat we links en rechts de twee versies van hetzelfde bestand hebben die moesten worden samengevoegd tot één. En in het midden hebben we het uiteindelijke samengevoegde resultaat.

Als een project veel branches, commits en gebruikers heeft, moet je apart zoeken op branch, gebruiker en datum:

Voordat je aan de slag gaat, is het ook de moeite waard om uit te leggen hoe je kunt begrijpen in welke branche we zitten.

In de rechter benedenhoek is er een knop met het label "Git: master". Wat volgt op "Git:" is de huidige branch. Als u op de knop klikt, kunt u veel nuttige dingen doen: overschakelen naar een andere tak, een nieuwe aanmaken, een bestaande hernoemen, enzovoort.

Werken met een archief

Handige sneltoetsen

Voor toekomstig werk moet u een paar zeer nuttige sneltoetsen onthouden:

1. CTRL+T — Haal de laatste wijzigingen op uit de externe repository (git pull).
2. CTRL+K — Maak een commit / bekijk alle huidige wijzigingen. Dit omvat zowel niet-gevolgde als gewijzigde bestanden (git commit).
3. CTRL+SHIFT+K — Dit is de opdracht voor het pushen van wijzigingen naar de externe repository. Alle commits die lokaal zijn gemaakt en nog niet in de externe repository staan, worden gepusht (git push).
4. ALT+CTRL+Z — Draai wijzigingen in een specifiek bestand terug naar de status van de laatste commit die in de lokale repository is gemaakt. Als u het hele project in de linkerbovenhoek selecteert, kunt u wijzigingen in alle bestanden ongedaan maken.

Wat willen we?

Om werk gedaan te krijgen, moeten we een basisscenario beheersen dat overal wordt gebruikt.

Het doel is om nieuwe functionaliteit in een aparte branch te implementeren en deze vervolgens naar een externe repository te pushen (dan moet je ook een pull request naar de hoofdbranch maken, maar dat valt buiten het bestek van deze les).

Wat is er nodig om dit te doen?

1. Haal alle huidige wijzigingen op in de hoofdtak (bijvoorbeeld "master").

2. Maak vanuit deze hoofdtak een aparte tak voor uw werk.

3. Implementeer de nieuwe functionaliteit.

4. Ga naar de hoofdvestiging en controleer of er tijdens het werken nieuwe wijzigingen zijn aangebracht. Zo niet, dan is alles in orde. Maar als er wijzigingen zijn, dan doen we het volgende: ga naar de werktak en rebase de wijzigingen van de hoofdtak naar de onze. Als alles goed gaat, dan geweldig. Maar het is heel goed mogelijk dat er conflicten ontstaan. Ze kunnen namelijk gewoon van tevoren worden opgelost, zonder tijd te verspillen in de externe opslagplaats.

   Vraag je je af waarom je dit zou moeten doen? Het is een goede manier en voorkomt dat er conflicten ontstaan ​​na het pushen van je branch naar de lokale repository (er is natuurlijk een mogelijkheid dat er nog steeds conflicten zullen optreden, maar het wordt veel kleiner).

5. Push uw wijzigingen naar de externe repository.

Hoe krijg ik wijzigingen van de externe server?

We hebben een beschrijving toegevoegd aan de README met een nieuwe commit en willen deze wijzigingen ontvangen. Als er zowel in de lokale repository als in de externe repository wijzigingen zijn aangebracht, worden we uitgenodigd om te kiezen tussen een samenvoeging en een rebase. We kiezen ervoor om te fuseren.

Voer CTRL+T in :

Je kunt nu zien hoe de README is veranderd, dwz de wijzigingen van de externe repository zijn binnengehaald, en in de rechter benedenhoek kun je alle details zien van de wijzigingen die van de server kwamen.

Maak een nieuwe branch op basis van master

Alles is hier eenvoudig.

Ga naar de rechter benedenhoek en klik op Git: master . Selecteer + Nieuwe tak .

Laat het Checkout filiaal aangevinkt en voer de naam van het nieuwe filiaal in. In ons geval: dit zal leesmij-verbeteraar zijn .

Git: master verandert dan in Git: readme-improver .

Laten we parallel werk simuleren

Om conflicten te laten verschijnen, moet iemand ze creëren.

We zullen de README bewerken met een nieuwe commit via de browser, waardoor parallel werk wordt gesimuleerd. Het is alsof iemand wijzigingen in hetzelfde bestand heeft aangebracht terwijl we eraan werkten. Het resultaat zal een conflict zijn. We zullen het woord "fully" van regel 10 verwijderen.

Implementeer onze functionaliteit

Onze taak is om de README te wijzigen en een beschrijving aan het nieuwe artikel toe te voegen. Dat wil zeggen, het werk in Git gaat via IntelliJ IDEA. Voeg dit toe:

De wijzigingen zijn gedaan. Nu kunnen we een commit maken. Druk op CTRL+K , wat ons het volgende geeft:

Voordat we een commit maken, moeten we goed kijken naar wat dit venster te bieden heeft.

In de sectie Commit-bericht schrijven we tekst die is gekoppeld aan de commit. Om het vervolgens te maken, moeten we op Commit klikken .

We schrijven dat de README is gewijzigd en maken de commit aan. Er verschijnt een waarschuwing in de linker benedenhoek met de naam van de commit:

Controleer of de hoofdvestiging is gewijzigd

We hebben onze taak volbracht. Het werkt. We hebben testen geschreven. Alles is in orde. Maar voordat we naar de server pushen, moeten we nog steeds controleren of er in de tussentijd wijzigingen zijn opgetreden in de hoofdtak. Hoe kon dat gebeuren? Heel eenvoudig: iemand krijgt een taak na jou, en die iemand maakt deze sneller af dan jij jouw taak afmaakt.

We moeten dus naar de master branch gaan. Om dit te doen, moeten we doen wat wordt weergegeven in de rechter benedenhoek in de onderstaande schermafbeelding:

Druk in de master branch op CTRL+T om de laatste wijzigingen van de externe server op te halen. Als je kijkt naar wat er verandert, kun je gemakkelijk zien wat er is gebeurd:

Het woord "fully" is verwijderd. Misschien heeft iemand van marketing besloten dat het niet zo geschreven mocht worden en heeft hij de ontwikkelaars de taak gegeven om het bij te werken.

We hebben nu een lokale kopie van de laatste versie van de master branch. Ga terug naar leesmij-verbeteraar .

Nu moeten we de wijzigingen van de master branch rebaseen naar de onze. Wij doen dit:

Als je alles correct hebt gedaan en met mij hebt meegedaan, zou het resultaat een conflict in het README-bestand moeten laten zien:

Hier hebben we ook veel informatie om te begrijpen en op te nemen. Hier wordt een lijst weergegeven met bestanden (in ons geval één bestand) die conflicten hebben. We kunnen kiezen uit drie opties:

1. accepteer de jouwe - accepteer alleen wijzigingen van readme-improver.
2. accepteer die van hen - accepteer alleen wijzigingen van master.
3. samenvoegen — kies zelf wat u wilt behouden en wat u wilt weggooien.

Het is niet duidelijk wat er is veranderd. Als er wijzigingen zijn in de master branch, moeten ze daar nodig zijn, dus we kunnen onze wijzigingen niet zomaar accepteren. Dienovereenkomstig selecteren we samenvoegen :

Hier kunnen we zien dat er drie delen zijn:

1. Dit zijn de wijzigingen van readme-improver.
2. Het samengevoegde resultaat. Voor nu is het wat er was vóór de veranderingen.
3. De wijzigingen van de master branch.

We moeten een samengevoegd resultaat produceren dat iedereen tevreden zal stellen. Als we bekijken wat er VOOR onze wijzigingen is gewijzigd, realiseren we ons dat ze simpelweg het woord "fully" hebben verwijderd. Oke geen probleem! Dat betekent dat we het ook in het samengevoegde resultaat zullen verwijderen en vervolgens onze wijzigingen zullen toevoegen. Nadat we het samengevoegde resultaat hebben gecorrigeerd, kunnen we op Toepassen klikken .

Vervolgens verschijnt er een melding die ons vertelt dat de rebase succesvol was:

Daar! We hebben ons eerste conflict opgelost met IntelliJ IDEA.

Push wijzigingen naar de externe server

De volgende stap is om de wijzigingen naar de externe server te pushen en een pull-aanvraag te maken. Om dit te doen, drukt u gewoon op CTRL+SHIFT+K . Dan krijgen we:

Aan de linkerkant is er een lijst met commits die niet naar de externe repository zijn gepusht. Aan de rechterkant staan ​​alle bestanden die zijn gewijzigd. En dat is het! Druk op Push en je zult geluk ervaren :)

Als de push succesvol is, ziet u een melding zoals deze in de rechter benedenhoek:

Bonus: een pull-aanvraag maken

Laten we naar een GitHub-repository gaan en we zien dat GitHub al weet wat we willen:

Klik op Verzoek vergelijken en ophalen . Klik vervolgens op Pull-aanvraag maken . Omdat we de conflicten van tevoren hebben opgelost, kunnen we deze nu bij het maken van een pull-aanvraag meteen samenvoegen:

Dat is het voor nu!