4.1 Git mentális modellje

← 4. Git és verziókezelés a gyakorlatban

4.1 Git mentális modellje – miért nem elég a „commit és push"

Áttekintő

A legtöbb junior fejlesztő megtanul néhány Git parancsot, és azt hiszi, érti a Gitet. A valóság az, hogy a parancsokat lehet gépelni értés nélkül – és ez pontosan az, ami bajt okoz, ha valami elromlik.

Ez az alfejezet nem arról szól, hogyan kell Gitet használni. Arról szól, hogyan kell Gitet érteni. Ha van mentális modelled arról, mi történik a háttérben, sokkal kevesebbet fogsz pánikba esni, és sokkal ritkábban fogsz commitot elveszíteni vagy branch-et összekeverni.

Amit ebből az alfejezetből viszel magaddal:

  • Megérted, hogy a Git snapshot-alapú, nem diff-alapú
  • Tudod, mi a különbség staging, lokális repo és remote repo között
  • Felismered a leggyakoribb junior félreértéseket, mielőtt te is beleesnél

Részletes leírás

Mi a Git valójában? – Nem az, amit gondolsz

A legtöbb ember azt gondolja, a Git nyomon követi a változásokat – vagyis azt, hogy melyik sort adtad hozzá, melyiket törölted. Ez részben igaz, de nem ez a Git belső működésének az alapja.

A Git snapshot-alapú rendszer.

Minden egyes commit egy teljes pillanatfelvétel az egész projektről, nem egy „diff" az előző állapothoz képest. A Git persze optimalizál – ha egy fájl nem változott, nem tárolja el újra, hanem csak mutat az előző verzióra. De konceptuálisan minden commit egy teljes kép.

Miért számít ez? Mert ha így gondolsz a Gitre, sok dolog logikusabbá válik:

  • Miért lehet visszatérni bármely korábbi commithoz? Mert az a commit tartalmazza az egész projekt akkori állapotát.
  • Miért lehet egymástól független branch-eken dolgozni? Mert mindegyik a saját snapshot-sorozatán halad.
  • Miért tud a Git olyan gyorsan checkout-olni? Mert nem kell kirakni a diffeket – csak betölti az adott pillanatfelvételt.

A háromszintű modell: working directory, staging area, repository

Ez a Git megértésének legfontosabb pontja. Háromféle hely van, ahol a kód „tartózkodhat":

[Fájlrendszer]        [Staging area]        [Lokális repository]
(working directory)   (.git/index)          (.git/objects)
       │                    │                      │
       │── git add ────────►│                      │
       │                    │── git commit ────────►│
       │◄── git checkout ───────────────────────── │

1. Working directory (munkaterület)

Ez az, amit te látsz. A fájlok a gépeden, ahogy szerkeszted őket. A Git figyeli, de még nem tud róluk hivatalosan – nem vette nyilvántartásba.

2. Staging area (előkészítési terület)

Ez egy közbenső terület. A git add paranccsal ide pakolod azokat a változtatásokat, amelyeket szándékozol commitolni. Nem mentés – ez egy „szándéknyilatkozat".

Miért létezik? Azért, hogy ne kelljen mindent egyszerre commitolni. Ha egyszerre dolgozol két független dolgokon, két külön commitot tudsz belőlük csinálni – az egyiket staging-be teszed, commitolod, aztán a másikat.

3. Lokális repository

A git commit parancs viszi át a staging area tartalmát ide. Ez már valódi mentés – legalábbis lokálisan. A commit létrejött, van neve (SHA hash), és időbélyege.

De még nem látja senki más.

A negyedik szint: remote repository

[Lokális repository]        [Remote repository]
  (.git/objects)              (GitHub / GitLab / Bitbucket)
         │                          │
         │── git push ─────────────►│
         │◄── git pull ─────────────│
         │◄── git fetch ────────────│

A remote az a szerver, ahol a csapat közösen dolgozik. A git push viszi fel a lokális commitjaidat. A git pull hozza le a mások által feltolt változtatásokat.

Nagyon fontos különbség:

  • git commit = lokálisan mentve, de a csapat nem látja
  • git push = a csapat is látja

Ez az oka, hogy egy commit elveszhet, ha csak a gépeden van és az elromlik. A push az igazi mentés.

Amit a juniorok általában félreértenek

Félreértés #1: „A staging area a mentés"

Sokan azt gondolják, hogy git add után már biztonságban van a változtatás. Nem. A staging area elvész, ha visszaállítod a working directory-t.

Félreértés #2: „A commit feltölt a szerverre"

Nem. A commit csak lokálisan rögzíti a változtatást. Push kell a feltöltéshez. Sokat látok juniorokat, akik azt hiszik, hogy commitoltak és az elment a GitHub-ra – aztán a laptop elvész, és a kód is.

Félreértés #3: „A Git fájlokat tárol, nem verziókat"

A Git az egész projekt állapotát tárolja pillanatfelvételként. Nem fájlokat kezel egymástól függetlenül – az egész repo állapotát rögzíti.

Félreértés #4: „A git reset veszélyes, ne nyúljak hozzá"

Ez részben igaz – de attól függ, milyen flaggel használod. A git reset --soft csak a staging-ből veszi vissza a commitot, a kódon nem változtat. A git reset --hard törli a változtatásokat is. Ez nem paranoia, hanem tudatosság.

Félreértés #5: „Ha nincs neten, nem tudok Gitet használni"

A Git teljesen offline működik. A lokális repository teljes értékű – commit, branch, history, minden. Csak a push/pull/fetch igényel kapcsolatot a remote-hoz.

Hogyan néz ki egy commit valójában?

Egy commit a következő információkat tartalmazza:

  • Tree – mutatókészlet az összes fájlra és mappára (snapshot)
  • Parent – az előző commit SHA hash-e
  • Author – ki és mikor
  • Message – a commit üzenet
  • SHA hash – a commit egyedi azonosítója (pl. a3f9c1b)

A SHA hash nem random – az összes fenti adat alapján számítódik. Ha bármelyik bit megváltozik, más hash lesz. Ez garantálja, hogy a Git history nem módosítható észrevétlenül.

Életszerű példák

Szituáció 1: A „de én commitoltam!" katasztrófa

Szituáció: Péter egy egész délutánon dolgozik egy feature-n. Az esti daily standup-on azt mondja: „Push-oltam." Másnap a teamlead nem látja a kódot a repo-ban.

Mi történt? Péter commitolt, de elfelejtett push-olni. A commit csak a lokális gépén volt.

Tanulság: git push a commit után kötelező, ha azt akarod, hogy mások lássák. Nézd meg mindig a GitHub/GitLab felületen, hogy valóban felment-e.

Szituáció 2: „Miért nem látom a változtatásaimat?"

Szituáció: Anna módosít egy fájlt, majd git status-t futtat. Látja, hogy a fájl módosítva van. De git diff --cached nem mutat semmit.

Mi történt? Anna nem futotta a git add-ot. A változtatás csak a working directory-ban van, a staging area üres.

Tanulság: A git status megmutatja, hol tart a kódod a háromszintű modellben. Olvasd el figyelmesen, mielőtt commit-olsz.

Szituáció 3: A véletlen commit

Szituáció: Márton debuggoláshoz ideiglenesen hozzáad egy console.log("XYZ DEBUG") sort. Aztán git add .-tal mindent staging-be tesz, majd commitol. Csak reviewban veszi észre, hogy a debug sor is felment.

Mi történt? A git add . mindent hozzáad staging-hez, nem csak azt, amit szándékoztál.

Tanulság: Soha ne használj vakon git add .-ot. Ehelyett:

  • git add <fájlnév> – csak egy fájlt ad hozzá
  • git add -p – interaktívan, fájlonként vagy chunkonként

Szituáció 4: „Ahol a commit, ott a branch"

Szituáció: Zsuzsa a main branch-en dolgozik, véletlenül oda commitol egy feature-t. Pánikba esik.

Mi történt? Semmi visszafordíthatatlan. A commit létezik, csak a branch-et kell rendbe tenni.

Megoldás (egyszerűsítve):

  1. Csinálj egy új branch-et onnan, ahol most vagy: git checkout -b my-feature
  2. Állítsd vissza a main-t az előző állapotba: git reset --hard origin/main
  3. A commitod ott van az my-feature branch-en

Tanulság: A Gitben szinte minden visszafordítható, ha értesz a mentális modellhez. A pánik oka legtöbbször a megértés hiánya.

Feladatok és tesztek

Gyakorlati feladat

Feladat: Commit életútja

Az alábbi parancsok listájából rendezd sorrendbe azt a szekvenciát, amely egy fájlt a „szerkesztéstől" egészen a „csapat látja"-ig visz. Minden lépésnél írd le, melyik szintre kerül a változtatás.

Elérhető parancsok (keverd sorba):

  • git push origin feature/bejelentkezes
  • git commit -m "Add login form validation"
  • git add src/login.js
  • # szerkeszted a login.js fájlt
  • git checkout -b feature/bejelentkezes

Elvárt válasz struktúra:

  1. [parancs] → változtatás helye: [working directory / staging / lokális repo / remote]

Tesztkérdések

1. kérdés: Mit tárol egy Git commit valójában?

a) Az előző commithoz képest megváltozott sorok listáját
b) A projekt összes fájljának teljes tartalmát (pillanatfelvételt)
c) Csak a módosított fájlokat, a többi fájlra mutatókkal
d) A változtatásokat gzip-ben tömörítve

Helyes válasz: c) – Ez a legpontosabb: a Git pillanatfelvételt tárol, de optimalizálásból csak a valóban megváltozott fájlokat tárolja újra; a többire mutatót tart. Konceptuálisan az egész repo állapotát jelenti.

2. kérdés: Mi a staging area szerepe?

a) Az, ahol a Git automatikusan menti a munkát
b) Egy előkészítési terület, ahol kiválasztod, mit akarsz commitolni
c) A remote repository helyi másolata
d) Biztonsági mentés, ha a commit elromlik

Helyes válasz: b)

3. kérdés: Péter lefuttatja: git commit -m "feature kész". Látja-e ezt a csapat a GitHubon?

a) Igen, a commit automatikusan szinkronizál
b) Nem, push szükséges hozzá
c) Csak akkor, ha online van
d) Igen, ha a branch tracking be van állítva

Helyes válasz: b)

4. kérdés: Mi a különbség a git fetch és a git pull között?

a) Nincs különbség, szinonimák
b) A fetch letölti a remote változtatásokat, de nem mergeli; a pull letölti és mergeli is
c) A fetch lassabb, a pull gyorsabb
d) A fetch csak brancheket tölt le, a pull commitokat

Helyes válasz: b)

5. kérdés: Amelyik tévhitet azonosítsd: „A Git diff-alapú rendszer, minden commit az előző commithoz képest tárolja a változtatásokat."

a) Ez teljesen igaz
b) Ez tévhit – a Git snapshot-alapú, minden commit a teljes projekt pillanatfelvétele
c) Ez igaz csak a fájlokra, de a mappákra nem
d) Ez igaz a git diff parancs esetén, de máshol nem

Helyes válasz: b)

6. kérdés: Anna lefuttatja a git add -p parancsot. Mit tesz ez?

a) Az összes módosított fájlt staging-be teszi
b) Interaktívan, chunk-onként kérdezi meg, mit adjon hozzá a staging-hez
c) Csak a py kiterjesztésű fájlokat adja staging-hez
d) A staging area tartalmát mutatja meg

Helyes válasz: b)

7. kérdés: Mi egy SHA hash a Git kontextusban?

a) A fájlok tömörítési algoritmusának neve
b) A commit egyedi azonosítója, amelyet a commit tartalmából számít a Git
c) A remote repository titkosítási kulcsa
d) A staging area sorszáma

Helyes válasz: b)

8. kérdés: Melyik állítás IGAZ a Git offline működéséről?

a) Git csak internetes kapcsolattal működik
b) git commit és git log offline is futtatható, csak push/pull/fetch igényel hálózatot
c) Git offline módban automatikusan a staging area-ba menti a commitokat
d) Git teljesen offline képes, beleértve a push és pull parancsokat is

Helyes válasz: b)

9. kérdés: Mit jelent a git reset --soft HEAD~1?

a) Törli az utolsó commitot és az összes változtatást
b) Visszavonja az utolsó commitot, de a változtatásokat staging-ben hagyja
c) Visszavonja az utolsó commitot, és a változtatásokat a working directory-ban hagyja
d) Visszaállítja a remote állapotát

Helyes válasz: b)

10. kérdés: Márton módosít egy fájlt, majd lefuttatja: git status. A fájl megjelenik a „Changes not staged for commit" szekció alatt. Melyik szinten van most a változtatás?

a) Staging area
b) Lokális repository
c) Working directory
d) Remote repository

Helyes válasz: c)

Következő alfejezet: 4.2 – Branch stratégiák: Git Flow, GitHub Flow, trunk-based

Scroll to Top