Bevezető helyett
Helló! Ma egy verziókezelő rendszerről fogunk beszélni, nevezetesen a Git-ről.
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:

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)
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:- A létrehozott, de a tárhoz még fel nem vett fájl állapota „nem követett”.
- Amikor módosítjuk azokat a fájlokat, amelyeket már hozzáadtunk a Git tárolóhoz, akkor azok állapota „módosított”.
- 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.
- 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".

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

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

git status

- 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.
git add *.txt
Az állapot ellenőrzéséhez a már ismert parancsot használjuk:
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"
Az összes commit megtekintéséhez írja be:
git log

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


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

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

- 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

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

git branch -a

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

git checkout -b feature/update-txt-files

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:

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

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: 

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

git status

git add *.txt

git commit

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


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

Hasznos link
- Hivatalos Git dokumentáció . Referenciaként ajánlom.