2026.07.24.
Kódolás, keretrendszerek

Kihasználható javítások git commit történetben

Temesvári László

A kód története is számít: Hogyan legyen átlátható a commit történet?

Ha csapatban dolgozunk, a Git commit története nem csak egy technikai napló – olyan, mint egy közösen írt regény. Ha fejezetekbe rendezett, követhető és értelmes, mindenki boldog. Ha viszont tele van olyan commitokkal, mint „kis javítás” vagy „még egy próba”, akkor a kód review pokollá válhat, és a visszakeresés lehetetlen. Nézzük, hogyan alakíthatjuk a commit történetünket egy átlátható, tanulmányozható narratívává, ahol a commitok maguk is javíthatók.

Miért fontos az átláthatóság?

Képzeld el, hogy egy héttel később vissza kell menned egy bug-hoz, vagy új kollégának el kell magyarázni, hogy egy feature hogyan épült fel. Ha a commitok logikailag tagoltak és világos címmel rendelkeznek, percek alatt megtalálod a relevant változtatásokat. A code review is gyorsabb és hatékonyabb lesz, mert a reviewer egyértelműen látja, mire fókuszáljon egy-egy commitban. Ez nem csak elvárás, hanem tisztelet a csapattagok és a jövőbeli önmagunk felé.

Az alapok: Jól formázott, atomi commitok

Az első lépés a jó commit üzenet. Egy rövid, tárgyszerű cím (50 karakter alatt), majd egy részletes leírás, amely elmagyarázza a *miért*-et, nem csak a *mit*-et. Használj igék jelen időben: „Javít”, „Hozzáad”, „Refaktorál” – ne „javítottam” múlt időben.

// Rossz commit üzenet:
// fix

// Jó commit üzenet:
// Javít: SQL injection sebezhetőség a felhasználói bejelentkezésnél

// Még jobb, részletes leírással:
// Javít: SQL injection sebezhetőség a felhasználói bejelentkezésnél
// 
// A `UserAuth::checkLogin()` függvény közvetlenül interpolálta
// a felhasználói bemenetet a SQL query-be. Paraméterezett lekérdezéssel
// helyettesítettem a mysqli_stmt használatával.
// 
// Érintett fájlok:
// - /app/Models/UserAuth.php
// - /tests/Unit/UserAuthTest.php

A commit legyen atomi – egy logikai egységet, egy változtatást foglaljon magában. Ne keverj össze egy bugfix-et egy formázási változtatással.

A kulcs: Javítható commitok interaktív rebase-sel

Itt jön a varázslat: a commit történet nem kész kőbe vésve. Ha már elkövettünk néhány gyenge commit-ot (pl. „wip” vagy „tmp”), interaktív rebase segítségével átalakíthatjuk őket *utólag*.

Tegyük fel, hogy az utolsó 4 commitunkat szeretnénk átnézni:

git rebase -i HEAD~4

Megjelenik egy szerkesztő, ahol összevonhatunk (squash), átnevezhetünk (reword), vagy akár át is rendezhetünk (reorder) commitokat. Ez lehetővé teszi, hogy a lokális, kísérletező munkánkat egy tiszta, előadható történetté alakítsuk, mielőtt push-olnánk.

Gyakori buktató: Ne rebase-olj olyan commitokat, amelyeket már publikáltál (push-oltál) a közös ágra! Az csak lokálisan, a saját ágadon legyen divat.

Példa egy frontend változtatás commit történetére

Készítünk egy új gombkomponenst. Ne így nézzen ki a történet:

1. add button 2. style fix 3. add icon 4. fix click event

Hanem így, két atomi, jól elnevezett committal:

1. commit: „Hozzáad: Új elsődleges gomb komponens Bootstrap alapon”

<!-- ButtonComponent.php - A backend rész -->
<button class="btn btn-primary" id="actionButton"><?= htmlspecialchars($label) ?></button>
// frontend/styles/components/_button.scss
.btn-primary-custom {
  @extend .btn-primary;
  transition: all 0.2s ease;
  &:hover {
    transform: translateY(-1px);
    box-shadow: 0 4px 8px rgba(0,0,0,0.1);
  }
}

2. commit: „Bővít: Gomb kattintás esemény jQuery-vel és visszajelzés”

// frontend/js/button.js
$(document).ready(function() {
  $('#actionButton').on('click', function() {
    var $btn = $(this);
    $btn.prop('disabled', true).html('<span class="spinner-border spinner-border-sm" role="status"></span> Feldolgozás...');
    
    // Szimuláljunk egy API hívást
    setTimeout(function() {
      $btn.prop('disabled', false).text('Sikeres!');
      $('#feedback').removeClass('d-none').addClass('alert-success').text('Művelet végrehajtva.');
    }, 1500);
  });
});

Így a code review két elkülöníthető részen tud összpontosítani: előbb a struktúra és stílus, majd az interakciók.

Code review és a commit történet szimbiózisa

A jó commit történet a code review alapja. Reviewerként nem kell egy 20 fájlt módosító, összevont commit diff-jében bolyongani. Ehelyett logikailag lépésről lépésre követheted a változást. Ha egy commit túl nagy vagy több dolgot csinál, nyugodtan kérj részekre bontást – erre való a „javíthatóság”.

Különösen hasznos, ha a commit leírásban hivatkozol a feladatkezelő rendszerbeli jegyre (pl. „Lásd: PROJ-123”), de ne csak az ID legyen ott. Magyarázd el a kontextust is.

Összegzés: A történet, amit szeretnél olvasni

Az átlátható commit történet nem öncélú pedanteria. Időt takarít meg, csökkenti a hibák kockázatát és javítja a csapat kommunikációját. A titok a tudatosságban és az eszközök (mint az interaktív rebase) bátor használatában rejlik. Következő alkalommal, mielőtt git commit -m "valami"-t írsz, állj meg egy pillanatra: *”Ha hat hónap múlva visszanézném, érteném, mi történt itt?”* Ha a válasz igen, mehetsz tovább. Ha nem, írd át. A jövőbeli kollégád (aki lehet, hogy te magad vagy) meg fogja köszönni.

Végső soron a kódunk minőségét nem csak a működés, hanem az elkészítésének története is meghatározza. Legyen ez a történet egy jó olvasmány.

Kapcsolódó cikkek