Commitolni — mi ez, formázási szabályok és munka Git-tel

Mi az a commit Git-ben

A commit Git-ben egy objektum, amely a projekt fájljainak állapotát tárolja egy adott időpontban. Minden commit tartalmazza az összes követett fájl pillanatképét, egy hivatkozást a szülő commitra és metaadatokat. Más verziókezelő rendszerekkel ellentétben a Git content-addressable storage-t használ — minden objektum a tartalmának SHA-1 hash-je alapján azonosítható.

Amikor a fejlesztő commitolja a változtatásokat, a Git létrehoz egy commit objektumot, amely tárolja: tree objektum (fájlszerkezet), szülő commit hash, szerző, committer, dátum és üzenet. Ez az objektum megváltoztathatatlan — létrehozás után a commit nem módosítható a hash megváltoztatása nélkül. Éppen ez a megváltoztathatatlanság garantálja a projekt történetének integritását.

# Változtatások előkészítése és commitolás
git add index.html style.css
git commit -m "Fix responsive layout on mobile devices"

# Commit részleteinek megtekintése
git log --oneline -3
git show HEAD

# Összes változtatás előkészítése és commitolás egy lépésben
git commit -a -m "Update dependencies to latest versions"

A commitok irányított aciklikus gráfot (DAG) alkotnak, ahol minden új commit az előzőre hivatkozik. Ez lehetővé teszi a történetben való navigálást, a változtatások visszavonását és a kódbázis fejlődésének elemzését. A Git DAG szerkezetének megértése — a haladó commit munka alapja.

Hogyan kell helyesen commitolni a változtatásokat

A commit folyamata Git-ben két szakaszból áll: a változtatások hozzáadása a staging area-hoz (index) és a commit létrehozása. A staging area lehetővé teszi a fejlesztő számára, hogy kiválassza, mely változtatások kerüljenek a commitba, még akkor is, ha sok fájl módosult a munkakönyvtárban.

Az atomicitás szabálya — a jó commit kulcsfontosságú elve. Minden commitnak egy logikai változtatást kell tartalmaznia. Ha a fejlesztő hibát javít és refaktorálja a kódot — ez két különböző commit. Az atomi commitok egyszerűsítik a kódellenőrzést, a változtatások visszavonását és a történet elemzését.

Commitolás előtt érdemes ellenőrizni: maradt-e a kódban hibakeresési kimenet, kommentezett blokk vagy véletlen változtatás. Ehhez a git diff --cached parancsot használjuk, amely megmutatja, pontosan mi kerül a commitba. További ellenőrzés a git status segítségével megjeleníti a staging area fájljainak listáját.

• Ellenőrizd a változtatásokat — git diff --cached mutatja mi kerül a commitba
• Ellenőrizd a minőséget — kódnak linteren és teszteken kell átmennie commit előtt
• Írj üzenetet — érthető leírás a változtatás céljáról
• Ellenőrizd a staged-et — git status megerősíti a fájllistát

A commit üzenetek írásának szabályai

A commit üzenet — a változtatás dokumentációja a jövőbeli fejlesztők számára. Egy jó üzenet válaszol a kérdésekre: mi változott és miért. A Conventional Commits konvenció (Angular csapat, 2016) számos projekt számára szabvánnyá vált és meghatározza a formátumot: típus(terület): leírás.

Egy jó commit üzenet címsorból (max 50 karakter) és törzsből (opcionális, soronként max 72 karakter) áll. A címsor felszólító módban íródik: „Add” nem „Added” vagy „Adds”. A Capitalization és pont a címsor végén nem használatos — ez a Git nemzetközi egyezménye.

Rossz üzenet: „fix things” vagy „update” — nem hordoz információt. Egy hónap múlva a fejlesztő nem fogja érteni, mi változott pontosan és miért. Jó üzenet: „fix(payment): handle timeout in stripe callback” — azonnal világos, hol és mit javítottak.

Gyakori hibák commitoláskor

A fejlesztők, különösen a kezdők, gyakran követnek el tipikus hibákat commitoláskor. A leggyakoribb — túl nagy commit, amelyben tucatnyi változtatás keveredik. Az ilyen commitot nem lehet részlegesen visszavonni, a kódellenőrzés pedig kínszenvedéssé válik.

A második leggyakoribb hiba — rossz commit üzenet. Az olyan üzenetek, mint „fix”, „update”, „changes” vagy „wip” nem adnak kontextust a jövőbeli fejlesztőknek. Hat hónap múlva senki sem fogja emlékezni, mit javítottak pontosan. A szabály egyszerű: képzeld el, hogy egy év múlva nézed a történetet és próbálsz megtalálni egy konkrét változtatást.

Harmadik hiba — nem lefordított vagy nem működő kód commitolása. Commit után a kódnak legalább fordulnia kell. Nem törött build — alapvető követelmény minden közös ágba kerülő commithoz. Ehhez commit előtt a build és tesztek futtatása szükséges.

Negyedik hiba — commit bizalmas adatokkal. API kulcsok, jelszavak és tokenek nem kerülhetnek a Git történetbe. Ha egy titok már commitolva van, nem elég egyszerűen törölni egy új commitban — a teljes történetből ki kell törölni a git filter-branch vagy BFG Repo-Cleaner segítségével.

Haladó technikák a commitokkal való munkához

A Git eszközöket biztosít a commit történet kezeléséhez. Az egyik leghasznosabb a git commit --amend, amely lehetővé teszi az utolsó commit kiegészítését új változtatásokkal vagy az üzenet javítását. Ez kényelmes, ha a fejlesztő elfelejtett hozzáadni egy fájlt vagy hibázott az üzenetben.

# Utolsó commit üzenet javítása
git commit --amend -m "fix(auth): correct token validation logic"

# Kihagyott fájl hozzáadása az utolsó commithoz
git add missed-file.txt
git commit --amend --no-edit

# Interaktív rebase az utolsó 3 commithoz
git rebase -i HEAD~3

Az Interactive rebase — egy hatékony eszköz a történet átírására. Lehetővé teszi commitok összevonását (squash), üzenetek módosítását (reword), sorrend változtatását (reorder) és commitok törlését (drop). Azonban a rebase megváltoztatja a történetet, ezért csak olyan helyi commitokra alkalmazzák, amelyek még nincsenek feltolva a távoli repozitóriumba.

A commitok visszavonására két megközelítés létezik. git revert létrehoz egy új commitot, amely visszavonja az előző változtatásait — biztonságos módszer, amely megőrzi a történetet. A git reset törli a commitokat a történetből — veszélyes, ha a commitok már fel lettek tolva. Csapatmunkában csak a git revert használatos a publikált commitok visszavonására.