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

4.3 Commit üzenetek írása – miért számít és hogyan csináld jól

Áttekintő

Minden fejlesztő írta már le, hogy fix vagy stuff. Gyors, kényelmes, senki nem szól érte azonnal. De 3 hónappal később, amikor keresed, hogy mikor romlott el a login, ott állsz egy git log-gal, amiben 200 fix van egymás alatt – és fogalmad sincs, melyikbe nyúlj bele.

A commit üzenet nem magadnak írod. Egy időgép üzenet a jövőbeli csapatodnak – beleértve önmagadat. Ez az alfejezet megmutatja, hogyan írj olyan commit üzenetet, ami ténylegesen hasznos.

Amit megtanulsz:

• Miért nem elég a "fix" és társai
• A jó commit üzenet felépítése
• Conventional Commits szabvány – amit a legtöbb cég használ
• Mikro-commitok vs. nagy commitok: mikor melyik?

---

Részletes leírás

Miért számít a commit üzenet?

A kód megmutatja, mit csináltál. A commit üzenet megmutatja, miért.

git log --oneline

Ha ez a kimenet:

a3f2c1d fix
b7e9d2a update
c1a8f3b changes
d4b2e1c wip
e9c3a1b final
f2d8b4c final2

…akkor ez a git log értéktelen. Semmiféle információt nem ad arról, mi változott, miért, és milyen sorrendben.

Ezzel szemben:

a3f2c1d fix(auth): handle expired JWT token on refresh
b7e9d2a feat(user): add email verification on registration
c1a8f3b docs: update API endpoint examples in README
d4b2e1c refactor(cart): extract discount calculation to service
e9c3a1b test(order): add edge case for zero quantity items

Ránézésre tudod, mi történt, melyik részben, és mit érintett.

---

A jó commit üzenet anatómiája

Az imperative mood (felszólító mód) szabálya

Commit üzenetet úgy írj, mintha azt mondanád a kódbázisnak, mit tegyen – nem múlt időben.

Miért? Mert a git maga is így ír (pl. Merge branch 'feature/login'). Konzisztens és olvasható.

Hossz: 72 karakter a subject sorban

Az első sor (subject) maximum 72 karakter. Ez nem önkényes szám: a legtöbb git kliens, GitHub, és terminál ennél töri el a megjelenítést.

Ha több magyarázatot akarsz adni, hagysz egy üres sort, és utána jön a body (törzs):

Fix null pointer in cart when user has no address

Previously the checkout flow assumed all users have a saved
address. When a guest user tried to checkout, the address
resolver threw NullPointerException. Added null check and
redirect to address form instead.

Fixes: #234

A body-t nem kötelező mindig megírni. De ha a változtatás oka nem nyilvánvaló a kódból, érdemes.

---

Conventional Commits szabvány

A legtöbb modern fejlesztői csapat valamilyen konvenciót követ. Az egyik legelterjedtebb a Conventional Commits:

<type>(<scope>): <description>

Típusok:

Scope (opcionális): melyik modult/réteget érinti (pl. auth, cart, user, api).

Példák:

feat(user): add profile picture upload
fix(auth): prevent login with unverified email
refactor(order): split OrderService into smaller services
test(payment): add unit tests for discount calculation
chore: update dependencies to latest patch versions
docs(api): add authentication examples to README

Ez a szabvány azért hasznos, mert:

• Automatikusan generálható belőle CHANGELOG
• CI/CD pipeline dönthet a verzió-ütközésekről (semantic versioning)
• Áttekinthető a PR és a git history

Nem minden cég használja pontosan ezt a formátumot – de valamilyen konvenciót szinte mindenki követ. Ha új csapatba kerülsz, az egyik első dolog: megnézni a git history-t és megérteni, milyen stílust követnek.

---

Mikro-commitok vs. nagy commitok

Ez az egyik legnagyobb vita a fejlesztői csapatoknál. Az igazság: mindkét véglet problémás.

A mikro-commit csapda

fix typo
fix typo again
fix typo for real this time
remove debug log
remove another debug log

Ha minden apróságot külön committolsz, a history zajos lesz és nehéz nyomon követni, mi tartozik össze.

A "monolithic commit" csapda

WIP - nagy feature

1 commit, 47 fájl változtatás, 800 sor kód. Ha ebben van egy bug, nem tudod visszacsinálni a problémás részt anélkül, hogy az egészet visszavonnád.

Az egyensúly: logikai egységek

Egy commit = egy logikai egység. Nem egy fájl, nem egy nap munkája – egy összefüggő gondolat.

Például egy user regisztrációs funkció megvalósítása értelmes commitokra bontva:

feat(user): add User model with email and password fields
feat(user): add registration endpoint with input validation
feat(user): send verification email on registration
test(user): add unit tests for registration flow

Mindegyik önmagában is értelmes. Mindegyik visszavonható anélkül, hogy a többi összetörne.

---

Amend és interactive rebase (egy szó a tiszta history-ról)

Ha még nem pusháltál, és az utolsó commit üzenetét el akarod javítani:

git commit --amend

Megnyílik a szerkesztő, átírhatod az üzenetet. FONTOS: csak ha még nem pusháltad! Pusholt commitot ne amendálj – rewrite-olja a history-t és konfliktust okoz a csapatnak.

---

Életszerű példák

1. példa: A "fix" kommit következménye

Kata csapatában production-ban leáll a checkout. A tech lead kinyitja a git log-ot:

3 days ago: fix - Kata
3 days ago: update - Bence
4 days ago: changes - Kata
5 days ago: fix - Márton

Senki nem tudja, melyik commit okozta a problémát. Kézzel kell végigmenni mind a négyen, megnézni a diff-et, megérteni, mit csinált.

Ha helyette ez lenne:

3 days ago: fix(checkout): handle missing shipping address - Kata
3 days ago: feat(product): add bulk discount calculation - Bence
4 days ago: refactor(cart): extract price calculation to service - Kata
5 days ago: fix(auth): prevent double login on back button - Márton

A tech lead azonnal tudná: Kata checkout-hoz nyúlt 3 napja. Ott kezdi.

---

2. példa: Onboarding egy új projektbe

Dávid új céghez kerül. Az első hét egyik feladata: megérteni, hogyan alakult ki az autentikációs rendszer.

git log --oneline --all -- src/auth/

Ha a commit history olvasható (Conventional Commits szerint), Dávid 10 perc alatt látja:

• Mikor vezették be a JWT-t
• Mikor váltottak refresh token-re
• Melyik bugfix miért kellett

Ha a history csupa fix és update, ugyanez a megértés napokba telik.

---

3. példa: PR review a commit history alapján

Anna senior fejlesztő. Kap egy nagy PR-t reviewra: 8 commit, 300 sor változtatás.

Ha a commitok logikusan vannak bontva:

feat(payment): add Stripe payment gateway integration
feat(payment): add payment status webhook handler
feat(payment): add payment history page
test(payment): add integration tests for Stripe webhooks
fix(payment): handle Stripe rate limit errors gracefully

Anna commit-ról commitra halad, mindegyiket önmagában érti. A review gyors és pontos.

Ha minden egyetlen add payment feature commitban van, Anna az egész diff-et egyszerre látja, kontextus nélkül. A review lassabb, és valószínűbb, hogy valami kicsúszik.

---

Tesztfeladatok

1. feladat – Commit üzenetek átírása

Írd át az alábbi rossz commit üzeneteket a Conventional Commits szabvány szerint! Minden esetben találj ki egy rövid, értelmes leírást is.

1. fix
2. update user stuff
3. added tests
4. changes for the PR
5. final version

---

2. feladat – Melyik a jobb commit?

Minden párból válaszd ki a jobb commit üzenetet és indokold meg egy mondatban!

A pár:

• A: fix login
• B: fix(auth): redirect to login page when session expires

B pár:

• A: feat(user): add email verification flow with token expiry
• B: add email verification

C pár:

• A: refactor
• B: refactor(order): extract discount logic to DiscountService

---

3. feladat – Conventional Commits típus azonosítása

Melyik type illik az alábbi változtatásokhoz?

1. Új API végpont hozzáadása felhasználó törléshez
2. Szóköz eltávolítása egy fájl végéről
3. README kiegészítése telepítési útmutatóval
4. Bejelentkezési hiba javítása, ahol a jelszó kis-nagybetű érzékeny volt
5. Jest tesztkönyvtár verzió frissítése 29-ről 30-ra
6. Login sebesség javítása egy felesleges DB lekérdezés eltávolításával

---

4. feladat – Commit stratégia tervezése

Az alábbi feladatot kell implementálnod: Felhasználói profil szerkesztése – név, email, profilkép módosítása.

Tervezz meg 3-5 logikus committ ehhez a feature-höz! Minden commithoz add meg a típust, scope-ot és a leírást Conventional Commits formátumban.

---

5. feladat – Igaz vagy hamis?

Döntsd el, melyik állítás igaz és melyik hamis! Ha hamis, javítsd ki egy mondatban.

1. A commit üzenet subject sorát mindig múlt időben kell írni.
2. Ha egy commit üzenet nem egyértelmű, a diff-ből mindig meg lehet érteni, miért történt a változtatás.
3. A git commit --amend biztonságosan használható pusholt commiton is.
4. Egy "logikai egység" commit lehet több fájlt is érinteni.
5. A Conventional Commits szabvány kötelező minden cégnél.
6. A commit history segíthet az onboarding során egy új fejlesztőnek.
7. A chore típusú commit általában nem tartalmaz funkcionális változtatást.

---

6. feladat – Git log elemzése

Az alábbi git log-ot látod egy projekten:

e3f2c1a fix(checkout): handle missing billing address on order submit
d7a9b2c feat(product): add product variant support (color, size)
c1e8f3b test(product): add unit tests for variant price calculation
b4d2e1c fix(product): correct variant stock count after purchase
a9c3a1b feat(cart): persist cart items across sessions
f2d8b4c docs: add API documentation for cart endpoints

Kérdések:

1. Melyik commit javított egy hibát a termék-modulban vásárlás után?
2. Milyen dokumentáció változott a legújabb commit előtt?
3. Ha a checkout-on van egy bug, melyik commitba érdemes először belenézni?
4. Mit vezettek be a feat(cart) commitban?

---

7. feladat – Micro vs. monolith commit döntés

Az alábbi szituációkban döntsd el: érdemes-e külön commitba tenni, vagy össze lehet vonni? Indokold!

1. Javítasz egy elírást a kommentben, majd rögtön utána javítasz egy logikai hibát ugyanabban a fájlban.
2. Megírsz egy új service osztályt és hozzá unit teszteket.
3. Refaktorálsz egy modult (3 fájl), majd hozzáadsz egy teljesen új végpontot.
4. Eltávolítasz egy console.log sort és egy unused import-ot ugyanabban a fájlban.