A Git használatának első lépései: átfogó útmutató kezdőknek

Bevezető helyett

Helló! Ma egy verziókezelő rendszerről fogunk beszélni, nevezetesen a Git-ről. Semmi közöd a programozáshoz, ha nem ismered/érted a Git-et. De az a szépség, hogy nem kell minden Git parancsot és funkciót a fejében tartania ahhoz, hogy folyamatosan használhassa. Ismernie kell egy sor parancsot, amely segít megérteni mindent, ami történik.

Git alapjai

A Git egy elosztott verziókezelő rendszer a kódunkhoz. Miért van rá szükségünk? Az elosztott csapatoknak szükségük van valamilyen rendszerre a munkájuk irányításához. Az idő múlásával bekövetkező változások nyomon követésére van szükség. Vagyis lépésről lépésre látnunk kell, hogy mely fájlok és hogyan változtak. Ez különösen fontos, ha azt vizsgálja, hogy mi változott egyetlen feladat kontextusában, lehetővé téve a változtatások visszaállítását.

A Git telepítése

Telepítsük a Java-t a számítógépünkre.

Telepítés Windows rendszerre

Szokás szerint le kell töltenie és futtatnia kell egy exe fájlt. Itt minden egyszerű: kattintson az első Google linkre , hajtsa végre a telepítést, és kész. Ehhez a Windows által biztosított bash konzolt fogjuk használni. Windows rendszeren a Git Bash-t kell futtatnia. Így néz ki a Start menüben: Ez egy parancssor, amellyel dolgozhat. Annak érdekében, hogy ne kelljen minden alkalommal a projekt mappájába menni a Git megnyitásához, a jobb egérgombbal megnyithatja a parancssort a projekt mappájában a szükséges elérési úttal:

Telepítés Linuxra

Általában a Git a Linux disztribúciók része, és már telepítve van, mivel ez egy olyan eszköz, amelyet eredetileg Linux kernelfejlesztésre írtak. De vannak helyzetek, amikor nem. Az ellenőrzéshez meg kell nyitnia egy terminált, és ki kell írnia: git --version. Ha érthető választ kap, akkor semmit sem kell telepíteni. Nyisson meg egy terminált, és telepítse a Git-et az Ubuntu-ra . Az Ubuntu-n dolgozom, így meg tudom mondani, mit írjak rá: sudo apt-get install git.

Telepítés macOS-re

Itt is először ellenőriznie kell, hogy Git már ott van-e. Ha nem rendelkezik vele, akkor a legegyszerűbb módja annak, hogy letöltse a legújabb verziót innen . Ha az Xcode telepítve van, akkor a Git biztosan automatikusan telepítésre kerül.

Git beállítások

A Git felhasználói beállításokkal rendelkezik a munkát elküldő felhasználó számára. Ez logikus és szükséges, mert a Git ezt az információt a Szerző mezőhöz veszi a véglegesítés létrehozásakor. Állítson be felhasználónevet és jelszót az összes projekthez a következő parancsok futtatásával:

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

Ha módosítania kell egy adott projekt szerzőjét, eltávolíthatja a „--global” elemet. Ezzel a következőket kapjuk:

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

Egy kis elmélet...

Ahhoz, hogy belemerüljünk a témába, be kell mutatnunk néhány új szót és tettet...

• git adattár
• elkövetni
• ág
• összeolvad
• konfliktusok
• Húzni
• nyom
• egyes fájlok figyelmen kívül hagyása (.gitignore)

Stb.

Státuszok a Gitben

A Gitnek számos szobra van, amelyeket meg kell érteni és emlékezni kell:

• nyomon követhetetlen
• módosított
• megrendezett
• elkötelezett

Hogyan kell ezt érteni?

Ezek az állapotok a kódunkat tartalmazó fájlokra vonatkoznak:

1. A létrehozott, de a tárhoz még fel nem vett fájl állapota „nem követett”.
2. Amikor módosítjuk azokat a fájlokat, amelyeket már hozzáadtunk a Git tárolóhoz, akkor azok állapota „módosított”.
3. Az általunk módosított fájlok közül kiválasztjuk azokat, amelyekre szükségünk van, és ezek az osztályok „színpados” állapotba kerülnek.
4. A véglegesítés a szakaszos állapotú előkészített fájlokból jön létre, és a Git-tárba kerül. Ezt követően nincsenek „színpados” állapotú fájlok. De továbbra is lehetnek olyan fájlok, amelyek állapota "módosított".

Így néz ki:

Mi az elköteleződés?

A véglegesítés a fő esemény, ha verziókezelésről van szó. Tartalmazza az összes változtatást, amelyet a véglegesítés kezdete óta hajtottak végre. A kötelezettségvállalások úgy kapcsolódnak egymáshoz, mint egy külön linkelt lista. Pontosabban: van egy első commit. Amikor létrejön a második véglegesítés, tudja, mi következik az első után. És ezen a módon az információ nyomon követhető. A kötelezettségvállalásnak saját információi is vannak, úgynevezett metaadatok:

• a commit egyedi azonosítója, amely segítségével megkereshető
• a commit szerzőjének neve, aki létrehozta
• a kötelezettségvállalás létrehozásának dátuma
• egy megjegyzés, amely leírja, hogy mi történt a commit során

Így néz ki:

Mi az az ág?

Az elágazás egy mutató valamilyen kötelezettségvállalásra. Mivel a commit tudja, hogy melyik commit előzi meg, amikor egy ág egy commitra mutat, az összes korábbi commit rá is vonatkozik. Ennek megfelelően azt mondhatnánk, hogy annyi ága lehet, amennyit csak akar, ugyanarra a kötelezettségvállalásra mutatva. A munka elágazásokban történik, így amikor új véglegesítés jön létre, az ág a mutatót a legutóbbi véglegesítésre viszi.

A Git használatának megkezdése

Dolgozhat egy helyi adattárral egyedül és egy távoli tárolóval is. A szükséges parancsok gyakorlásához korlátozhatja magát a helyi tárolóra. Csak helyileg tárolja a projekt összes információját a .git mappában. Ha a távoli tárolóról beszélünk, akkor az összes információ valahol a távoli szerveren van tárolva: csak a projekt egy példánya tárolódik helyben. A helyi másolaton végrehajtott módosítások átküldhetők (git push) a távoli tárolóba. Az itt és az alábbi vitánkban a Git-tel való együttműködésről beszélünk a konzolon. Természetesen használhatunk valamilyen grafikus felhasználói felület alapú megoldást (például IntelliJ IDEA), de először ki kell deríteni, hogy milyen parancsokat hajtanak végre és mit jelentenek.

Munka a Git-tel egy helyi adattárban

Ezután azt javaslom, hogy kövesse a lépést, és hajtsa végre az összes lépést, amit a cikk olvasása közben tettem. Ez javítja az anyag megértését és elsajátítását. Hát jó étvágyat! :) Helyi tároló létrehozásához a következőket kell írnia:

git init

Ezzel létrehoz egy .git mappát a konzol aktuális könyvtárában. A .git mappa a Git-tárral kapcsolatos összes információt tárolja. Ne töröld ;) Ezután a fájlok hozzáadásra kerülnek a projekthez, és a "Nyomkövetés nélküli" állapotot kapják. A munkája aktuális állapotának ellenőrzéséhez írja be ezt:

git status

A mesterágban vagyunk, és itt is maradunk, amíg át nem váltunk egy másik ágra. Ez azt mutatja, hogy mely fájlok változtak, de még nem kerültek „színpados” állapotba. Ha hozzá szeretné adni őket a "staged" állapothoz, meg kell írnia a "git add" kifejezést. Itt van néhány lehetőségünk, például:

• git add -A — az összes fájl hozzáadása a "stage" állapothoz
• git add . — az összes fájl hozzáadása ebből a mappából és az összes almappából. Lényegében ez ugyanaz, mint az előző
• git add <fájlnév> — egy adott fájlt ad hozzá. Itt reguláris kifejezésekkel adhat hozzá fájlokat valamilyen minta szerint. Például git add *.java: Ez azt jelenti, hogy csak java kiterjesztésű fájlokat szeretne hozzáadni.

Az első két lehetőség egyértelműen egyszerű. A dolgok érdekesebbé válnak a legújabb kiegészítéssel, ezért írjuk:

git add *.txt

Az állapot ellenőrzéséhez a már ismert parancsot használjuk:

git status

Itt láthatja, hogy a reguláris kifejezés megfelelően működött: a test_resource.txt állapota "stage" állapotú. És végül, az utolsó lépés a helyi tárolóval való munkavégzéshez (a távoli tárolóval való munka során van még egy ;)) – új véglegesítés létrehozása:

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

Következő egy nagyszerű parancs az ág végrehajtási előzményeinek megtekintésére. Használjuk ki:

git log

Itt láthatja, hogy létrehoztuk az első véglegesítésünket, és ez tartalmazza a parancssorban megadott szöveget. Nagyon fontos megérteni, hogy ennek a szövegnek a lehető legpontosabban el kell magyaráznia, hogy mi történt a kötelezettségvállalás során. Ez sokszor segítségünkre lesz a jövőben. Egy érdeklődő olvasó, aki még nem aludt el, azon töprenghet, mi történt a GitTest.java fájllal. Most azonnal megtudjuk. Ehhez a következőket használjuk:

git status

Mint látható, még mindig "nyomon nem követett" és a szárnyakban vár. De mi van akkor, ha egyáltalán nem akarjuk hozzáadni a projekthez? Néha ez megtörténik. A dolgok érdekesebbé tétele érdekében próbáljuk meg megváltoztatni a test_resource.txt fájlunkat. Adjunk hozzá szöveget, és ellenőrizzük az állapotot:

git status

Itt jól látható a különbség a "nem követett" és a "módosított" állapotok között. A GitTest.java „untracked”, míg a test_resource.txt „módosított”. Most, hogy a fájlok módosított állapotban vannak, megvizsgálhatjuk a rajtuk végrehajtott módosításokat. Ezt a következő paranccsal lehet megtenni:

git diff

Vagyis itt jól látható, amit a szöveges fájlunkhoz adtam: hello world! Adjuk hozzá a módosításainkat a szövegfájlhoz, és hozzunk létre egy véglegesítést:

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

Az összes commit megtekintéséhez írja be:

git log

Amint látja, most két kötelezettségünk van. Ugyanígy adjuk hozzá a GitTest.java fájlt. Itt nincsenek megjegyzések, csak parancsok:

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

A .gitignore használata

Nyilvánvaló, hogy csak a forráskódot akarjuk a tárolóban tartani, semmi mást. Szóval mi más lehetne? Legalább a fejlesztői környezetek által generált lefordított osztályok és/vagy fájlok. Ahhoz, hogy a Git figyelmen kívül hagyja őket, létre kell hoznunk egy speciális fájlt. Tegye ezt: hozzon létre egy .gitignore nevű fájlt a projekt gyökerében. Ebben a fájlban minden sor egy figyelmen kívül hagyandó mintát jelent. Ebben a példában a .gitignore fájl így fog kinézni:

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

Lássuk:

• Az első sor az összes .class kiterjesztésű fájl figyelmen kívül hagyása
• A második sor az, hogy figyelmen kívül hagyja a "cél" mappát és mindent, amit tartalmaz
• A harmadik sor az összes .iml kiterjesztésű fájl figyelmen kívül hagyása
• A negyedik sor az .idea mappa figyelmen kívül hagyása

Próbáljunk meg egy példát használni. Ha látni szeretné, hogyan működik, adjuk hozzá a lefordított GitTest.classt a projekthez, és ellenőrizzük a projekt állapotát:

git status

Nyilvánvaló, hogy nem akarjuk véletlenül hozzáadni a lefordított osztályt a projekthez (a git add -A használatával). Ehhez hozzon létre egy .gitignore fájlt, és adjon hozzá mindent, amit korábban leírtunk: Most használjunk véglegesítést a .gitignore fájl hozzáadásához a projekthez:

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

És most az igazság pillanata: van egy összeállított GitTest.class osztályunk, amely "untracked", amelyet nem akartunk hozzáadni a Git tárolóhoz. Most látnunk kell a .gitignore fájl hatásait:

git status

Tökéletes! .gitignore +1 :)

Munka ágakkal és hasonlókkal

Természetesen a magányos fejlesztők számára kényelmetlen egy fiókban dolgozni, és lehetetlen, ha egy csapatban többen vannak. Ezért vannak fiókjaink. Ahogy korábban mondtam, az ág csak egy mozgatható mutató a commitokhoz. Ebben a részben megvizsgáljuk a különböző ágazatokban való munkát: hogyan lehet az egyik ágból a másikba egyesíteni a változásokat, milyen konfliktusok merülhetnek fel és még sok más. A tárhely összes ágának megtekintéséhez és annak megértéséhez, hogy melyikben van, a következőket kell írnia:

git branch -a

Láthatod, hogy csak egy mesterágunk van. Az előtte lévő csillag azt jelzi, hogy benne vagyunk. Egyébként a "git status" paranccsal is megtudhatod, melyik ágban vagyunk. Ezután több lehetőség is van ágak létrehozására (lehet több is – én ezeket használom):

• hozzon létre egy új ágat az alapján, amelyikben vagyunk (az esetek 99%-ában)
• ág létrehozása egy adott véglegesítés alapján (az esetek 1%-a)

Hozzunk létre egy ágat egy adott commit alapján

A commit egyedi azonosítójára fogunk hagyatkozni. Hogy megtaláljuk, ezt írjuk:

git log

A commit-ot az "added hello world..." megjegyzéssel emeltem ki. Ennek egyedi azonosítója: 6c44e53d06228f888f2f454d3cb8c1c976dd73f8. Szeretnék létrehozni egy "fejlesztési" ágat, amely ebből a commit-ból indul ki. Ehhez írom:

git checkout -b development 6c44e53d06228f888f2f454d3cb8c1c976dd73f8

Egy elágazás csak az első két véglegesítéssel jön létre a fő ágból. Ennek ellenőrzéséhez először győződjön meg arról, hogy vált egy másik ágra, és nézzük meg az ott végrehajtott véglegesítések számát:

git status
git log

És ahogy az várható volt, két kötelezettségünk van. Egyébként itt van egy érdekesség: ebben az ágban még nincs .gitignore fájl, így a lefordított fájlunk (GitTest.class) most "untracked" állapottal van kiemelve. Most újra áttekinthetjük fiókjainkat a következő írással:

git branch -a

Látható, hogy két ág van: "mester" és "fejlesztés". Jelenleg fejlesztés alatt állunk.

Hozzunk létre egy ágat a jelenlegi alapján

Az ág létrehozásának második módja az, hogy létrehozzuk egy másikból. Elágazást szeretnék létrehozni a fő ág alapján. Először is váltanom kell rá, a következő lépés pedig egy új létrehozása. Lássuk:

• git checkout master — váltson a fő ágra
• git állapot – ellenőrizze, hogy valóban a fő ágban vagyunk-e

Itt látható, hogy a master ágra váltottunk, a .gitignore fájl van érvényben, és a lefordított osztály már nincs kiemelve "untracked"-ként. Most létrehozunk egy új ágat a fő ág alapján:

git checkout -b feature/update-txt-files

Ha nem biztos abban, hogy ez az ág megegyezik-e a "master" ággal, egyszerűen ellenőrizheti a "git log" végrehajtásával és az összes véglegesítés megnézésével. Négynek kell lennie.

Konfliktusmegoldó

Mielőtt megvizsgálnánk, mi a konfliktus, beszélnünk kell az egyik ág egy másikba való egyesüléséről. Ez a kép az egyik ág egy másikba való egyesülésének folyamatát ábrázolja: Itt van egy fő ág. Egy bizonyos ponton egy másodlagos ág jön létre a fő ágból, majd módosul. A munka végeztével az egyik ágat össze kell olvasztanunk a másikkal. Nem fogom leírni a különféle jellemzőket: Ebben a cikkben csak egy általános megértést szeretnék közölni. Ha szüksége van a részletekre, maga is megkeresheti őket. Példánkban létrehoztuk a feature/update-txt-files ágat. Ahogy a fiók neve is jelzi, frissítjük a szöveget. Most új commit-ot kell létrehoznunk ehhez a munkához:

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

Most, ha a feature/update-txt-files ágat a masterbe akarjuk egyesíteni, akkor menjünk a masterbe, és írjuk be a "git merge feature/update-txt-files" kifejezést:

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

Ennek eredményeként a fő ág immár a feature/update-txt-fájlokhoz hozzáadott véglegesítést is tartalmazza. Ez a funkció hozzáadásra került, így törölhet egy szolgáltatási ágat. Ehhez ezt írjuk:

git branch -D feature/update-txt-files

Eddig minden világos, igaz? Bonyolítsuk a helyzetet: most tegyük fel, hogy újra meg kell változtatnia a txt fájlt. De most ez a fájl a master ágban is megváltozik. Vagyis párhuzamosan fog változni. A Git nem fogja tudni kitalálni, mit tegyünk, ha az új kódunkat a fő ágba akarjuk egyesíteni. Gyerünk! Létrehozunk egy új ágat a mester alapján, módosítjuk a text_resource.txt fájlt, és véglegesítést hozunk létre ehhez a munkához:

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

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

Lépjen a fő ágra, és frissítse ezt a szövegfájlt is ugyanabban a sorban, mint a szolgáltatás ágban:

git checkout master
… we updated test_resource.txt

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

És most a legérdekesebb pont: össze kell vonnunk a változtatásokat a feature/add-header ágból a masterbe. Mesterágban vagyunk, így csak annyit kell írnunk:

git merge feature/add-header

De az eredmény ütközés lesz a test_resource.txt fájlban: Itt láthatjuk, hogy a Git nem tudta önállóan eldönteni, hogyan egyesítse ezt a kódot. Azt mondja nekünk, hogy először meg kell oldanunk a konfliktust, és csak azután hajtjuk végre a kötelezettségvállalást. RENDBEN. Megnyitjuk az ütközést tartalmazó fájlt egy szövegszerkesztőben, és megnézzük: Ahhoz, hogy megértsük, mit csinált itt a Git, emlékeznünk kell, hogy milyen változtatásokat hajtottunk végre és hol, majd összehasonlítjuk:

1. A fő ágban ezen a sorban lévő változások a "<<<<<<< HEAD" és a "=======" között találhatók.
2. A feature/add-header ágban lévő változtatások a "=======" és a ">>>>>>> feature/add-header között találhatók.

A Git így közli velünk, hogy nem tudta kitalálni, hogyan hajtsa végre az egyesítést ezen a helyen a fájlban. Ezt a részt két részre osztotta a különböző ágakból, és arra kér bennünket, hogy mi magunk oldjuk meg az egyesülési konfliktust. Elfogadható. Bátran döntök úgy, hogy mindent eltávolítok, csak a „fejléc” szót hagyom meg: Nézzük meg a változtatások állapotát. A leírás kicsit más lesz. A „módosított” státusz helyett az „összevonás megszüntetése” történt. Tehát említhettünk volna egy ötödik státuszt? Szerintem erre nincs szükség. Lássuk:

git status

Meggyőzhetjük magunkat, hogy ez egy különleges, szokatlan eset. Folytassuk:

git add *.txt

Észreveheti, hogy a leírás csak a „git commit” kifejezést javasolja. Próbáljuk meg ezt írni:

git commit

És pont így, megcsináltuk – megoldottuk a konfliktust a konzolban. Természetesen ez egy kicsit könnyebben megtehető integrált fejlesztői környezetekben. Például az IntelliJ IDEA-ban minden olyan jól van beállítva, hogy az összes szükséges műveletet közvetlenül elvégezheti. De az IDE-k sok mindent csinálnak "a motorháztető alatt", és gyakran nem értjük, hogy pontosan mi is történik ott. És ha nincs megértés, akkor problémák merülhetnek fel.

Távoli adattárak használata

Az utolsó lépés az, hogy kitaláljon néhány további parancsot, amelyek szükségesek a távoli tárolóval való együttműködéshez. Mint mondtam, a távoli adattár egy olyan hely, ahol a tárat tárolják, és ahonnan klónozhatja. Milyen távoli adattárak vannak? Példák:

• A GitHub a legnagyobb tárolási platform a tárhelyekhez és az együttműködési fejlesztésekhez. Korábbi cikkekben már leírtam.
  Kövess engem a GitHubon . Gyakran mutatom be a munkámat azokon a területeken, amelyeket munka céljából tanulok.

• A GitLab egy webalapú eszköz a DevOps életciklusához nyílt forráskóddal . Ez egy Git -alapú rendszer kódtárak kezelésére saját wikivel, hibakövető rendszerrel , CI/CD-folyamattal és egyéb funkciókkal.
  Miután a hír, hogy a Microsoft megvásárolta a GitHubot, néhány fejlesztő megkettőzött projektjeit a GitLabban.

• A BitBucket a Mercurial és Git verzióvezérlő rendszereken alapuló webszolgáltatás projektek tárolására és együttműködési fejlesztésére. Egy időben nagy előnye volt a GitHubbal szemben, mivel ingyenes privát adattárakat kínált. Tavaly a GitHub is ingyenesen bemutatta ezt a képességet mindenkinek.

• Stb…

Amikor távoli tárolóval dolgozik, először klónoznia kell a projektet a helyi tárolóba. Ehhez exportáltam azt a projektet, amit helyben készítettünk, és most mindenki klónozhatja magának a következő írással:

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

Jelenleg a projekt teljes helyi példánya létezik. Ahhoz, hogy megbizonyosodjon arról, hogy a projekt helyi példánya a legújabb, le kell húznia a projektet a következő írással:

git pull

Esetünkben a távoli adattárban jelenleg semmi sem változott, így a válasz: Már aktuális. De ha bármilyen módosítást végzek a távoli tárolóban, a helyi frissítés frissül, miután lekértük őket. És végül az utolsó parancs az adatok küldése a távoli adattárba. Ha valamit helyileg csináltunk, és el akarjuk küldeni a távoli tárolóba, először létre kell hoznunk egy új véglegesítést helyileg. Ennek demonstrálására adjunk hozzá még valamit a szövegfájlunkhoz: Most valami egészen megszokott dolog – létrehozunk egy véglegesítést ehhez a munkához:

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

A parancs, amely ezt a távoli tárolóba küldi, a következő:

git push

Nos, ennyit akartam mondani. Köszönöm a figyelmet. Kövess engem a GitHubon , ahol különféle remek példaprojekteket teszek közzé személyes tanulmányaimmal és munkámmal kapcsolatban.

Hasznos link

• Hivatalos Git dokumentáció . Referenciaként ajánlom.