Git és verziókezelés a mobilfejlesztésben: mi ez, alapvető parancsok és hogyan működik

Verziókezelés és Git: mi ez?

Git egy elosztott verziókezelő rendszer (VCS), amelyet Linus Torvalds hozott létre 2005-ben a Linux kernel fejlesztéséhez. A centralizált rendszerekkel (SVN, CVS) ellentétben a Git a projekt teljes előzményét minden fejlesztő számítógépén tárolja. Ez azt jelenti, hogy internetkapcsolat nélkül is végezhet commitokat, böngészheti az előzményeket és hozhat létre ágakat.

A Git pillanatképekkel (snapshot) működik — minden commit elmenti az összes projektfájl állapotát a mentés időpontjában. Ha egy fájl nem változott, a Git hivatkozást hoz létre az előző verzióra, helyet spórolva. A GitHub elemzése (2025) szerint az átlagos repository 1200 commitot és 15 ágat tartalmaz.

Az IT Sectr-nél 2017 óta használjuk a Git-et minden projektben. Tapasztalataink szerint a megfelelő Git-konfiguráció az első naptól kezdve akár 30%-kal is csökkenti a csapat egyesítésre és konfliktusmegoldásra fordított idejét. A Git de facto szabvánnyá vált — minden modern IDE (Android Studio, Xcode, VS Code) és CI/CD rendszer támogatja.

# Alap Git beállítás
git config --global user.name "Az Ön Neve"
git config --global user.email "az@email.com"

# Új repository létrehozása
git init my-project
cd my-project

# Fájlok hozzáadása és commit
git add README.md
git commit -m "Initial commit"

# Munka távoli repository-val
git remote add origin https://github.com/user/my-project.git
git push -u origin main

A fenti kód az alapvető sorrendet mutatja: repository inicializálása, első commit és közzététel távoli szerveren. A git init parancs létrehoz egy rejtett .git mappát, amely a teljes projekt előzményeit tárolja. Minden git commit létrehoz egy helyreállítási pontot, amelyhez bármikor visszatérhet.

Alapfogalmak: Repository, Branch, Commit

A három alapfogalom — Repository, Branch és Commit — megértése elengedhetetlen bármely verziókezelő rendszer használatához. A repository egy tároló a teljes projekt számára. A commit a fájlok mentett állapota. A Branch egy külön fejlesztési vonal.

Repository lehet helyi (az Ön számítógépén) vagy távoli (GitHub, GitLab szerveren). Minden fejlesztő klónozza a távoli repository-t a gépére, és egy helyi másolattal dolgozik. A változtatások push (küldés) és pull (lehívás) útján szinkronizálódnak. Az elosztott verziókezelésben minden fejlesztő tárolja az előzmények teljes másolatát.

Branch (ág) egy mutató az egyik commitra. Az ágak lehetővé teszik a párhuzamos fejlesztést: az egyik fejlesztő egy új funkción (feature branch) dolgozik, a másik egy hibát javít (hotfix branch), a harmadik egy kiadást készít elő (release branch). A GitLab Flow (2025) szerint az átlagos projektben egyszerre 3–5 aktív ág van.

Commit a változás egysége. Minden commit egyedi hash-t (SHA-1), üzenetet, szerzőt és időbélyeget tartalmaz. Jó gyakorlat kis, értelmes commitok készítése leíró üzenetekkel — ez egyszerűsíti a Code Review-t és a változtatások visszavonását. A commitokon keresztüli verziókezelés megadja a projekt teljes előzményét.

Feature Branch

Feature Branch (funkció ág) egy ideiglenes ág, amelyet egy adott feladat fejlesztéséhez hoznak létre a develop vagy main ágból. A munka befejezése után az ágat Pull Requesten keresztül egyesítik vissza és törlik. Ez a gyakorlat lehetővé teszi a változtatások elkülönítését anélkül, hogy befolyásolná a fő kódbázis stabilitását.

Tipikus munkafolyamat: feature/add-login ág létrehozása → néhány commit elvégzése → Pull Request létrehozása → Code Review-n való átesés → egyesítés a develop ágba. Az IT Sectr-nél pontosan ezt a megközelítést használjuk: minden Jira feladat egy külön feature ágnak felel meg. Ez egyszerűsíti a változtatások nyomon követését és szükség esetén a visszavonást.

Rebase vs Merge

Merge létrehoz egy egyesítési commitot, amely két ágat egyesít. Megőrzi a teljes előzményt, beleértve a párhuzamos fejlesztési vonalakat is. A Rebase átírja az előzményeket: commitokat vesz át az egyik ágból, és "újraalkalmazza" azokat egy másik ágra, lineáris előzményt hozva létre.

A Merge jobban megfelel nyilvános ágak és nagy csapatok számára, ahol a kronológia fontos. Rebase kényelmes személyes feature ágakhoz a PR létrehozása előtt — tisztábbá és érthetőbbé teszi az előzményeket. A rebase-t azonban soha nem szabad olyan ágakon alkalmazni, amelyeken más fejlesztők dolgoznak, mert átírja az előzményeket.

# Feature ág létrehozása és váltás
git checkout -b feature/add-login main

# Munka az ágban
git add login-screen/
git commit -m "Add login screen layout"

# Rebase a legfrissebb main-re PR előtt
git checkout main && git pull
git checkout feature/add-login
git rebase main

# Push távoli repository-ba
git push origin feature/add-login

Ez a példa egy tipikus munkafolyamatot mutat: feature ág létrehozása a main-ből, néhány commit és rebase a tiszta lineáris előzmények eléréséhez a felülvizsgálatra küldés előtt. Ez a megközelítés minimalizálja az egyesítési konfliktusokat.

Git Flow vs Trunk-Based Development

Git Flow és a Trunk-Based Development a verziókezelés két fő stratégiája, amelyek meghatározzák, hogy egy csapat hogyan szervezi a munkát Git-tel. A választás a csapat méretétől, a kiadások gyakoriságától és a stabilitási követelményektől függ.

Git Flow egy szigorú modell több állandó ággal: main (kiadási kód), develop (aktuális fejlesztés), feature/* (új funkciók), release/* (kiadás előkészítése) és hotfix/* (sürgős javítások). Ez a modell a világos kiadási ciklusokkal rendelkező projektekhez jó (pl. 1.0, 2.0 verziójú mobilalkalmazások).

Trunk-Based Development egyetlen fő ággal (trunk/main) rendelkező megközelítés, amelybe az összes fejlesztő naponta többször egyesíti a változtatásokat. Feature flagok segítségével rejtik el a befejezetlen funkciókat. Ez a megközelítés a webfejlesztésben és az induló vállalkozásoknál népszerű, ahol a szállítási sebesség fontos.

Git Flow

Git Flow, amelyet Vincent Driessen javasolt 2010-ben, továbbra is az egyik legnépszerűbb modell marad. Fő előnye a kód szigorú szétválasztása az életciklus szakaszai szerint. A main ág csak kiadási kódot tartalmaz, a develop az aktuális fejlesztést, a feature ágak pedig elkülönítik az új funkciókat egymástól.

A hotfix ágak a main-ből jönnek létre sürgős javításokhoz, és az egyesítés után visszakerülnek mind a main-be, mind a develop-ba. A release ágak a develop-ból jönnek létre, amikor a csapat készen áll a kiadásra. Csak hibajavítások és metaadatok (verzió, build) kerülnek bele. A kiadás után a release ág beolvad a main-be és a develop-ba. Egy JetBrains felmérés (2024) szerint a csapatok 37%-a használja a Git Flow-t. Ez a verziókezelési modell továbbra is a szabvány a rögzített kiadásokkal rendelkező projekteknél.

# Git Flow példa: munka kezdése egy kiadáson
git checkout -b release/1.2.0 develop

# Hibajavítás a release ágban
git commit -m "Fix login button crash"

# Kiadás befejezése — egyesítés a main-be és develop-ba
git checkout main
git merge --no-ff release/1.2.0
git tag -a 1.2.0

git checkout develop
git merge --no-ff release/1.2.0

# A release ág törlése
git branch -d release/1.2.0

A kód bemutatja a release ág létrehozását, stabilizálását és egyesítését a fő ágakba. A --no-ff jelző garantálja az egyesítési commitot, megőrizve azt az információt, hogy a változtatások a release ágból származnak.

Pull Request és Code Review

Pull Request (PR) egy mechanizmus, amellyel a fejlesztő változtatásokat javasol az ágából a fő ágba. A PR a verziókezelés kulcseleme a csapatmunkában — nem csupán a kód egyesítésének módja, hanem a megbeszélés, felülvizsgálat és minőségellenőrzés folyamata. A GitLab-ben a hasonló mechanizmust Merge Request-nek (MR) hívják, de a lényeg ugyanaz: értesíteni a csapatot a változtatásokról és jóváhagyást szerezni.

Egy jó PR legyen kicsi (300 kódsorig terjedő), egyetlen feladatra összpontosítson, és tartalmazza a végrehajtott műveletek és azok okának leírását. Egy Google-tanulmány (2025) szerint a 400 sornál hosszabb PR-ek kétszer annyi időt vesznek igénybe a felülvizsgálathoz, és a hibák észlelésének valószínűsége 30%-kal csökken. A Code Review a kód ellenőrzése egy másik fejlesztő által az egyesítés előtt.

Az IT Sectr-nél kötelező Code Review-t alkalmazunk minden PR-hez. Ez nemcsak a kód minőségét javítja, hanem segíti a tudás terjesztését a csapaton belül is. A Code Review ellenőrzi: a kód követi-e az architektúra elveit, vannak-e hibák, elegendőek-e a tesztek, helyesen vannak-e elnevezve a változók. Az összes észrevételt a PR-ben vitatják meg az egyesítésig.

Platformok: GitHub, GitLab, Bitbucket

A Git egy protokoll, de az együttműködéshez szükség van egy verziókezelő platformra, amely webes felületet, hozzáférés-kezelést, CI/CD-t és felülvizsgálati eszközöket biztosít. Három platform uralja a piacot: GitHub, GitLab és Bitbucket.

GitHub a legnagyobb platform több mint 56 millió fejlesztővel. A Microsoft tulajdona, Actions (CI/CD), Pages (hosting), Discussions és Copilot szolgáltatásokat kínál. Az ingyenes csomag korlátlan privát repository-kat tartalmaz legfeljebb 3 fős csapatok számára. A GitHub népszerű a nyílt forráskódú közösségben.

GitLab egy teljes DevOps platform integrált CI/CD-vel, konténerregiszterrel és infrastruktúra-kezeléssel. A GitHubbal ellentétben a GitLab saját szerverre is telepíthető (Self-Managed). Az Atlassian Bitbucket-je szorosan integrált a Jira-val és a Confluence-szel, így ez a választás azoknak a csapatoknak, akik már használják az Atlassian ökoszisztémát.