1. Részletes útmutató a Githez kezdőknek

Ma egy verziókezelő rendszerről fogunk beszélni, nevezetesen a Git-ről.

Valóban nem lehet teljes értékű programozó anélkül, hogy ismerné és nem értené ezt az eszközt. Természetesen nem kell minden Git-parancsot és szolgáltatást 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? A 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.

Képzeljük el a következő helyzetet: van működő kódunk, minden jó benne, de aztán úgy döntünk, hogy javítunk vagy módosítunk valamit. Nem nagy baj, de a "fejlesztésünk" a program funkcióinak felét megtörte, és lehetetlenné tette a működést. Akkor most mi legyen? Git nélkül órákig kellene ülnöd és gondolkodnod, próbálva emlékezni arra, hogyan is volt minden eredetileg. De Git-tel csak visszavonjuk a kötelezettségvállalást – és ennyi.

Vagy mi van akkor, ha két fejlesztő egyszerre hajtja végre a saját kódját? Git nélkül az eredeti kódfájlokat másolják, és külön módosítják. Eljön az idő, amikor mindketten hozzá akarják adni a módosításaikat a főkönyvtárhoz. Mit tesz ebben az esetben?

Nem lesz ilyen probléma, ha Git-et használ.

A Git telepítése

Telepítsük a Java-t a számítógépére. Ez a folyamat némileg eltér a különböző operációs rendszereken.

Telepítés Windows alatt

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:

Most ez egy parancssor, amellyel dolgozhat.

Annak érdekében, hogy ne kelljen minden alkalommal a projektet tartalmazó mappá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. Ubuntu esetén ezt kell írni: sudo apt-get install git. És ennyi: mostantól bármilyen terminálban használhatja a Git-et.

Telepítés macOS-re

Itt is először ellenőrizni kell, hogy a Git már ott van-e (lásd fent, ugyanaz, mint a Linuxon).

Ha nem rendelkezik vele, akkor a legegyszerűbb módja annak, hogy letöltse a legújabb verziót . 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 meg kell változtatnia egy adott projekt szerzőjét (például egy személyes projekt esetében), 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

Hogy belemerüljünk a témába, be kellene vezetnünk néhány új szót és tettet... Különben nem lesz miről beszélni. Természetesen ez egy olyan zsargon, ami az angolból érkezik hozzánk, ezért zárójelben teszem a fordításokat.

Milyen szavakkal és cselekedetekkel?

  • 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. Más szavakkal, életciklusuk általában így néz ki:

  • 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 (például nincs szükségünk összeállított osztályokra), é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".

Í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, akkor (a második) 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.

Java webinar

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

Helyi tár létrehozásához a következőket kell írnia:

git init

Ezzel létrehoz egy rejtett .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 rendszer hozzáadja a fájlokat a projekthez, és a „Nincs követés” állapotot kapja. A munkája aktuális állapotának ellenőrzéséhez írja be ezt:

git állapot

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 ugyanaz, mint az előző;
  • git add <file name> — 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 állapot

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 „minden txt fájl hozzáadva a projekthez”

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 állapot

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 állapot

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 „köszönő szót hozzáadva! a test_resource.txt fájlhoz”

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 „addded GitTest.java”
git állapot

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 állapot

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 adja hozzá mindazt, 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 „hozzáadott .gitignore fájl”

É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 állapot

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

Munka ágakkal

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.

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 ág -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 az ágak létrehozására (lehet több is – 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 véglegesítést az "added hello world..." megjegyzéssel emeltük ki. Ennek egyedi azonosítója: 6c44e53d06228f888f2f454d3cb8c1c976dd73f8. Szeretnénk létrehozni egy "fejlesztési" ágat, amely ebből a véglegesítésből indul ki. Ehhez ezt írjuk:

git checkout -b fejlesztés 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 állapot
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 ág -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énk létrehozni a fő ág alapján. Először is át kell váltanunk 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 mutatja be:

Itt van egy fő águnk. 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.

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 „frissített txt fájlok”
git log

Ha a feature/update-txt-files ágat a masterbe akarjuk egyesíteni, akkor a masterbe kell lépnünk, és ki kell írnunk a "git merge feature/update-txt-files" kifejezést:

git checkout mester
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

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.

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

... módosítjuk a fájlt

git add *.txt
git commit -m „fejléc hozzáadva a txt-hez”

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 mester

… frissítettük a test_resource.txt fájlt

git add test_resource.txt
git commit -m „főfejléc hozzáadva a txt-hez”

É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ő fájlt egy szövegszerkesztőben, és látjuk:

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 úgy döntök, hogy mindent eltávolítok, csak a "fejléc" szót hagyom meg:

Nézzük meg a változá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 állapot

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.
  • 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.
  • 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áltuk a helyileg készített projektet Most mindenki klónozhatja magának a következő írással:

git klón 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égzünk 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 még valamit a szövegfájlunkhoz:

Most valami egészen megszokott számunkra – létrehozunk egy kötelezettségvállalást ehhez a munkához:

git add test_resource.txt
git commit -m "txt előkészítve a küldéshez"

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

git push

Egyenlőre ennyi!

Hasznos Linkek

2. Hogyan kell dolgozni a Git-tel az IntelliJ IDEA-ban

Ebben a részben megtudhatja, hogyan kell dolgozni a Gittel az IntelliJ IDEA-ban.

Szükséges bemenetek:

  1. Olvassa el, kövesse és értse meg az előző részt. Ez segít abban, hogy minden be legyen állítva és használatra kész.
  2. Telepítse az IntelliJ IDEA-t. Itt mindennek rendben kell lennie :)
  3. Szánjon egy órát a teljes mesteri képesség eléréséhez.

Dolgozzunk a demóprojekttel , amelyet a Gitről szóló cikkhez használtam.

Klónozza a projektet helyben

Itt két lehetőség van:

  1. Ha már van GitHub-fiókja, és szeretne valamit később leküldeni, jobb, ha elágazza a projektet, és klónozza a saját példányát. A villa létrehozásáról egy másik cikkben olvashat az Egy példa a villás munkafolyamatra cím alatt .
  2. Klónozza a tárolót, és tegyen meg mindent helyben, anélkül, hogy az egészet a szerverre küldhetné.

Projekt klónozásához a GitHubból ki kell másolnia a projekt hivatkozását, és át kell adnia az IntelliJ IDEA-nak:

  1. Másolja ki a projekt címét:

  2. Nyissa meg az IntelliJ IDEA alkalmazást, és válassza a "Get from Version Control" lehetőséget:

  3. Másolja és illessze be a projekt címét:

  4. A rendszer felkéri egy IntelliJ IDEA projekt létrehozására. Az ajánlat elfogadása:

  5. Mivel nincs összeállítási rendszer, a "Projekt létrehozása meglévő forrásokból" lehetőséget választjuk:

  6. Ezután ezt a gyönyörű képernyőt fogja látni:

Most, hogy rájöttünk a klónozásra, körülnézhet.

Első pillantás az IntelliJ IDEA-ra Git felhasználói felületként

Vessen egy pillantást a klónozott projektre: már most rengeteg információhoz juthat a verziókezelő rendszerről.

Először is a Verzióvezérlő ablaktáblát találjuk a bal alsó sarokban. Itt megtalálja az összes helyi változtatást, és megkapja a véglegesítések listáját (a „git log”-hoz hasonlóan).

Térjünk át a Log tárgyalására. Van egy bizonyos vizualizáció, amely segít megérteni, hogy pontosan hogyan haladt a fejlesztés. Például láthatja, hogy egy új ág jött létre a txt véglegesítéshez hozzáadott fejléccel, amelyet aztán egyesítettek a fő ággal. Ha rákattint egy véglegesítésre, a jobb sarokban láthatja a véglegesítéssel kapcsolatos összes információt: annak összes változását és metaadatait.

Ezen kívül láthatja a tényleges változásokat. Azt is látjuk, hogy ott egy konfliktus megoldódott. Az IDEA ezt is remekül mutatja be.

Ha duplán kattint a véglegesítés során megváltozott fájlra, látni fogjuk, hogyan oldódott meg az ütközés:

Megjegyezzük, hogy a bal és a jobb oldalon ugyanannak a fájlnak a két verziója van, amelyeket egybe kellett egyesíteni. És középen megvan a végső összevont eredmény.

Ha egy projektnek sok elágazása, véglegesítése és felhasználója van, akkor külön kell keresnie ág, felhasználó és dátum szerint:

Mielőtt elkezdené, azt is érdemes elmagyarázni, hogyan érthetjük meg, melyik ágban vagyunk.

A jobb alsó sarokban van egy „Git: master” feliratú gomb. Ami a „Git:” után következik, az az aktuális ág. Ha rákattint a gombra, sok hasznos dolgot tehet: átválthat másik ágra, létrehozhat újat, átnevez egy meglévőt stb.

Adattárral végzett munka

Hasznos gyorsbillentyűk

A jövőbeni munkához emlékeznie kell néhány nagyon hasznos gyorsbillentyűre:

  1. CTRL+T – Szerezze be a legújabb módosításokat a távoli adattárból (git pull).
  2. CTRL+K — Végrehajtás létrehozása / az összes jelenlegi módosítás megtekintése. Ez magában foglalja mind a nyomon nem követett, mind a módosított fájlokat (git commit).
  3. CTRL+SHIFT+K – Ez a parancs a távoli adattárba történő módosítások leküldésére. Minden helyileg létrehozott és még nem a távoli tárolóban lévő commit le lesz küldve (git push).
  4. ALT+CTRL+Z – Visszagörgetés egy adott fájlban a helyi lerakatban létrehozott utolsó véglegesítés állapotára. Ha a teljes projektet kiválasztja a bal felső sarokban, visszaállíthatja az összes fájl módosításait.

Mit akarunk?

A munka elvégzéséhez el kell sajátítanunk egy mindenhol használt alapforgatókönyvet.

A cél az, hogy új funkcionalitást implementáljunk egy külön ágban, majd egy távoli tárolóba toljuk el (akkor a fő ághoz is létre kell hozni egy lehívási kérelmet, de ez túlmutat a lecke keretein).

Mi szükséges ehhez?

  1. Szerezze be az összes aktuális változást a fő ágban (például "mester").

  2. Ebből a fő ágból hozzon létre egy külön ágat a munkájához.

  3. Alkalmazza az új funkciót.

  4. Lépjen a fő fiókba, és ellenőrizze, nem történt-e új változás a munka során. Ha nem, akkor minden rendben van. De ha változások történtek, akkor a következőt tesszük: menjünk a működő ágra, és alapozzuk át a változtatásokat a fő ágról a miénkre. Ha minden jól megy, akkor nagyszerű. De teljesen lehetséges, hogy lesznek konfliktusok. Amint megtörténik, ezek egyszerűen megoldhatók előre, anélkül, hogy időt veszítenénk a távoli tárolóban.

    Kíváncsi vagy, miért kell ezt megtenned? Jó modorú, és megakadályozza a konfliktusok előfordulását, miután az ágat a helyi adattárba helyezi (természetesen fennáll annak a lehetősége, hogy konfliktusok továbbra is előfordulnak, de ez sokkal kisebb lesz ).

  5. Tolja a módosításokat a távoli adattárba.

Hogyan lehet módosításokat lekérni a távoli szerverről?

Leírást adtunk a README-hoz egy új véglegesítéssel, és szeretnénk megkapni ezeket a változtatásokat. Ha mind a helyi, mind a távoli tárolóban történtek módosítások, akkor választhatunk az összevonás és az újrabázis között. Az egyesülés mellett döntünk.

Írja be a CTRL+T billentyűkombinációt :

Most láthatja, hogyan változott a README, azaz a távoli tárolóból behúzták a változtatásokat, a jobb alsó sarokban pedig a szerverről érkező változtatások minden részletét láthatja.

Hozzon létre egy új ágat a mester alapján

Itt minden egyszerű.

Lépjen a jobb alsó sarokban, és kattintson a Git: master elemre . Válassza az + Új ág lehetőséget .

Hagyja bejelölve a Checkout ág jelölőnégyzetét, és írja be az új fiók nevét. A mi esetünkben: ez a readme-improver lesz .

A Git: master ezután átvált Git: readme-improver -re .

Szimuláljunk párhuzamos munkát

Ahhoz, hogy konfliktusok jelenjenek meg, valakinek létre kell hoznia azokat.

A README-t egy új véglegesítéssel szerkesztjük a böngészőn keresztül, ezzel szimulálva a párhuzamos munkát. Mintha valaki változtatásokat végzett volna ugyanabban a fájlban, miközben dolgoztunk rajta. Az eredmény konfliktus lesz. A 10. sorból eltávolítjuk a „fully” szót.

Valósítsa meg funkcionalitásunkat

A mi feladatunk a README megváltoztatása és leírás hozzáadása az új cikkhez. Vagyis a Gitben végzett munka az IntelliJ IDEA-n keresztül megy. Adja hozzá:

A változtatások megtörténtek. Most létrehozhatunk egy commit. Nyomja meg a CTRL+K billentyűkombinációt , ami a következőket adja:

A commit létrehozása előtt alaposan meg kell vizsgálnunk, mit kínál ez az ablak.

A Commit Message részben a véglegesítéshez kapcsolódó szöveget írunk. Ezután a létrehozáshoz a Commit gombra kell kattintanunk .

Azt írjuk, hogy a README megváltozott, és létrehozzuk a véglegesítést. A bal alsó sarokban egy figyelmeztetés jelenik meg a véglegesítés nevével:

Ellenőrizze, hogy megváltozott-e a fő ág

Feladatunkat teljesítettük. Működik. Teszteket írtunk. Minden rendben. De mielőtt továbbítanánk a szerverre, még ellenőriznünk kell, hogy közben történt-e változás a fő ágban. Hogyan történhetett ez meg? Nagyon könnyen: valaki utánad kap egy feladatot, és az a valaki gyorsabban fejezi be, mint ahogy te befejezed.

Tehát a mester ágra kell mennünk. Ehhez az alábbi képernyőképen a jobb alsó sarokban látható módon kell eljárnunk:

A fő ágban nyomja le a CTRL+T billentyűkombinációt , hogy lekérje a legújabb módosításokat a távoli kiszolgálóról. Ha megnézi a változásokat, könnyen láthatja, mi történt:

A „fully” szót eltávolították. Lehet, hogy valaki marketinges úgy döntött, hogy ezt nem szabad így írni, és feladatot adott a fejlesztőknek, hogy frissítsék.

Mostantól rendelkezésünkre áll a főág legújabb verziójának helyi példánya. Menjen vissza a readme-improverhez .

Most át kell alapoznunk a változtatásokat a fő ágról a miénkre. Ezt csináljuk:

Ha mindent helyesen csinált, és velem követett, az eredmény ütközést mutat a README fájlban:

Itt is sok információ áll rendelkezésünkre, amit meg kell értenünk és magunkba szívnunk. Itt látható azon fájlok listája (esetünkben egy fájl), amelyek ütközésben vannak. Három lehetőség közül választhatunk:

  1. fogadja el a sajátját – csak a readme-improver módosításait fogadja el.
  2. fogadd el az övéket – csak a mestertől fogadj el változtatásokat.
  3. összevonás – válassza ki maga, mit szeretne megtartani, és mit dob ​​el.

Nem világos, hogy mi változott. Ha vannak változások, az a fő ág, akkor ott szükség van rájuk, így nem tudjuk egyszerűen elfogadni a változtatásainkat. Ennek megfelelően az egyesítést választjuk :

Itt láthatjuk, hogy három részből áll:

  1. Ezek a readme-improver változásai.
  2. Az összevont eredmény. Egyelőre az, ami a változások előtt létezett.
  3. A változások a fő ágból.

Összevont eredményt kell produkálnunk, amely mindenkit kielégít. Áttekintve, hogy mi változott a változtatásaink ELŐTT, rájövünk, hogy egyszerűen eltávolították a „fully” szót. Jó, semmi gond! Ez azt jelenti, hogy azt is eltávolítjuk az egyesített eredményből, majd hozzáadjuk a módosításainkat. Miután kijavítottuk az egyesített eredményt, kattintson az Alkalmaz gombra .

Ekkor megjelenik egy értesítés, amely arról tájékoztat, hogy az újrabázis sikeres volt:

Ott! Az első konfliktusunkat az IntelliJ IDEA segítségével oldottuk meg.

Tolja a módosításokat a távoli szerverre

A következő lépés a módosítások elküldése a távoli kiszolgálóra, és lekérési kérelem létrehozása. Ehhez egyszerűen nyomja meg a CTRL+SHIFT+K billentyűkombinációt . Akkor kapjuk:

A bal oldalon lesz egy lista azokról a véglegesítésekről, amelyek nem kerültek a távoli tárolóba. A jobb oldalon az összes megváltozott fájl látható. És ez az! Nyomd meg a Push-t és megtapasztalod a boldogságot :)

Ha a leküldés sikeres, a jobb alsó sarokban egy ehhez hasonló értesítést fog látni:

Bónusz: lehívási kérelem létrehozása

Lépjünk be egy GitHub-tárházba, és látjuk, hogy a GitHub már tudja, mit akarunk:

Kattintson az Összehasonlítás és kérés lekérése elemre . Ezután kattintson a Lekérési kérelem létrehozása elemre . Mivel az ütközéseket előre feloldottuk, most a lehívási kérelem létrehozásakor azonnal összevonhatjuk:

Egyenlőre ennyi!