Git Rebase és Merge: Hogyan Döntsünk Csapatmunkában?

Sziasztok! Ha együtt dolgoztok már egy projekten pár héten keresztül, biztosan előjött az a helyzet, hogy a feature branch-eken végzett munkát vissza kell vonatkoztatni a főágba. Itt szokott elindulni a vita: merge vagy rebase? Melyik a jobb? A válasz – mint mindig – az, hogy *attól függ*. Nézzük meg gyakorlatiasan, mikor érdemes melyiket használni, és hogyan kerüljük el a klasszikus buktatókat.

A két módszer lényege: Más filozófia, más eredmény

A merge lényegében egyesít. Létrehoz egy új, önálló commit-ot, amely összeköti a két ág történetét. A commit gráfod megőrzi a teljes történelmet, látható marad, hogy ki mikor dolgozott külön ágon. Ez egy biztonságos, nem destruktív művelet.

git checkout main
git merge feature/login-validator

A rebase viszont átírja a történelmet. Lényegében átemeli a teljes feature branch-ed commitjait a főág aktuális végére, mintha ott kezdtél volna el dolgozni. Az eredmény egy lineáris, tisztás történet – de a régi commit-ok hash-ei megváltoznak.

git checkout feature/login-validator
git rebase main

Mikor válasszunk merge-et?

A merge a csapatok többségénél az alapvető és biztonságos választás. Különösen akkor ajánlott: * Nyilvános ágak, főleg a main/master: Itt az őrizendő a történelem integritása. * Nagyobb, hosszabb fejlesztési ágak: Amikor több napos munkát végeztek külön, és fontos látni, hogy az egész feature hogyan egyesül. * Ha a csapat kezdőbb a Gitben: A merge megértése és visszacsinálása egyszerűbb.

PHP backend fejlesztés során gyakori példa: két fejlesztő dolgozik különböző API végpontokon.

// feature/api-user (Márió ága)
class UserController {
    public function getProfile($userId) {
        // Márió új profillekérdező logikája
        $user = $this->userRepository->findWithDetails($userId);
        return new JsonResponse($user);
    }
}

// feature/api-orders (Kati ága)
class OrderController {
    public function getUserOrders($userId) {
        // Kati rendeléslekérdezője
        $orders = $this->orderRepository->findByUser($userId);
        return new JsonResponse($orders);
    }
}

Ha mindketten a main-be mergelik a munkájukat, a történet tükrözi a párhuzamos fejlesztést. Konfliktus csak akkor keletkezik, ha ugyanazt a fájlt módosították.

Mikor nyer a rebase?

A rebase a *tisztaság* eszköze. Akkor hasznos, ha fontos, hogy a főág története lineáris és könnyen követhető legyen. Ideális helyzetek: * Helyi feature branch-ed takarítása: Mielőtt beadnád a pull requestet, rebase-olhatod a legfrissebb főágra, hogy a tesztelés simábban menjen. * Több kisebb, „piszkos” commit egyesítése: Interaktív rebase-al ( git rebase -i ) szépen össze tudod fogni a WIP commitjaidat. * Amikor a csapat konvenciója ezt diktálja: Egyes helyeken a lineáris történet a szabály.

Fontos frontend példa: dolgozol egy új jQuery komponensen egy Bootstrapes alapon, de közben a főágba került egy kritikus CSS javítás.

// feature/new-modal (eredeti commitod)
$(document).ready(function() {
    // Te 3 napja írtad ezt a modal kezelőt
    $('#myModal').on('show.bs.modal', function(event) {
        // ... a te régi logikád
    });
});

/* MAIN ÁG - közben bekerült egy fontos javítás */
.modal-backdrop {
    z-index: 1040; /* Ez hiányzott a te környezetedből! */
}

Ha simán merge-ölnél, a te kódod egy olyan környezetben futna teszteléskor, ami soha nem létezett (a CSS fix nélkül). Ha viszont rebase-olsz, a kódod a javított CSS *után* fog „keletkezni”, így a teszt pontosabb lesz, és a történeted egyszerű: „új modal, ami már a fix után készült”.

🚨 A Rebase Aranyszabályai és Buktatók

1. Aranyszabály: Csak lokálisan, még nem pusholt commitokon rebase-olj! Ha a branch-edet már felraktad a távoli repository-ba és mások is dolgoznak rajta, soha ne rebase-olj. A történelmed átírása őrületbe kergeti a kollégáidat. 2. Konfliktusok láncolódnak: Merge-nél egy összefoglaló konfliktusfeloldás van. Rebase-nél viszont *minden egyes commitodnál*, amely ütközik, megáll a folyamat és fel kell oldani. Hosszú branch-en fárasztó lehet. 3. Elveszíted a kontextust: A lineáris történet cserébe elveszíted a valós párhuzamos fejlesztés kontextusát. Néha egy merge commit egyértelműen mutatja: „ez a két feature egyszerre készült”.

Gyakorlati tanácsok csapatként

* Állapodjatok meg egy stratégiában! Legyen egyértelmű, hogy a main-be mindig merge-tel vagy mindig rebase-szel kerül be a kód. A keveredés a káoszhoz vezet. * Pull request előtt rebase érdemes: Mielőtt felküldöd a PR-t, rebase-old a legfrissebb főágra. Így a CI tiszta környezetben fut, és a reviewer egy tisztább diff-et lát. * Merge a közös branch-ekbe: Ha van egy develop ágatok, ahova mindenki beolvaszt, ott a merge biztonságosabb választás a kollektív történet miatt.

Összegzés: Egyensúly a biztonság és a tisztaság között

A merge a *biztonság* és a *teljes történet* eszköze. Tiszteletben tartja a párhuzamos munkát és nem ír át történelmet. A rebase a *precizitás* és *tisztaság* eszköze. Segít egy professzionális, lineáris commit history-t alakítani, de felelősséggel kell kezelni.

Egy tapasztalt csapat gyakran kombinálja: a feature branch-en dolgozva rebase-ol a főág friss változataira, hogy naprakész legyen, majd amikor a feature kész, a főágba egy gyors merge-tel beolvasztják. Így a feature ág története tiszta, a főágé pedig teljes.

Végül is, a legjobb stratégia az, amelyen a csapat egyetért, és amely kiszámítható. Beszéljétek meg, próbáljátok ki mindkettőt egy kisebb projekten, és fogadjátok el, hogy nincs szent grál – csak szituációhoz illő eszközök.