Feature Branch a Git-ben: mi ez, hogyan hozzunk létre és dolgozzunk ágakkal

Mi az a Feature Branch a Git-ben

Feature Branch (funkció ág) „ egy ideiglenes ág a Git-ben, amely a develop-ból jön létre egy külön funkcionalitás fejlesztésére. A hosszú életű main és develop ágakkal ellentétben a feature ágak korlátozott ideig léteznek „ néhány órától néhány hétig.

A feature branch fő célja, hogy elkülönítse az egy feladathoz kapcsolódó változtatásokat a kód többi részétől. A fejlesztő kísérletezhet, számos commitot készíthet, és akár el is ronthatja a kódot az ágában anélkül, hogy befolyásolná a csapat többi tagjának munkáját.

A fejlesztés befejezése után a feature ág visszakerül a develop-ba Pull Request segítségével, kötelező kód felülvizsgálattal. Az egyesítés után az ágat általában törlik, hogy a tároló tiszta maradjon.

Vincent Driessen, 2010 szerint a Git Flow modell feature ágakkal ipari szabvánnyá vált a különböző ágtípusok közötti egyértelmű felelősségmegosztásnak köszönhetően.

Munkafolyamat a Feature Branch-szel

Munkafolyamat a feature branch-szel a fejlesztő által minden új funkcióhoz végrehajtott lépések sorozatából áll. Ez a folyamat minimalizálja az egyesítési konfliktusokat és biztosítja a kód minőségének ellenőrzését.

1. Ág létrehozása a develop legutolsó commit-jából. A fejlesztő átvált a develop-ra, frissíti azt, és létrehoz egy új feature ágat.
2. Fejlesztés és commitek a feature ágban. A fejlesztő módosításokat végez, commitokat készít egyértelmű leírásokkal, és időszakosan push-olja az ágat a távoli tárolóba.
3. Szinkronizálás a develop-pal „ a fejlesztés során a főág előrehaladhat. A fejlesztő rebase-t vagy merge develop-et hajt végre a feature ágában.
4. Pull Request létrehozása „ amikor a funkció kész, a fejlesztő megnyit egy PR-t a kód felülvizsgálatához. A csapat ellenőrzi a kódot és megjegyzéseket hagy.
5. Egyesítés és törlés „ a PR jóváhagyása után az ág egyesítésre kerül a develop-ba, és törlődik mind helyileg, mind távolról.

Az időszakos szinkronizálás a develop-pal kritikus fontosságú. Minél tovább él egy feature ág a develop változtatásainak egyesítése nélkül, annál nagyobb a konfliktusok valószínűsége a végső egyesítésnél.

A feature ág szinkronizálásának gyakorisága

Feature ágak elnevezési szabályai

Ágak elnevezése „ a csapatal fegyelem fontos része. Az egységes elnevezési szabvány lehetővé teszi, hogy gyorsan meghatározzuk, melyik feladaton dolgoznak és ki végzi azt.

• feature/név „ a feature/ előtag a klasszikus Git Flow-ban használatos. Példa: feature/added-auth-module.
• feature/JIRA-123-leírás „ kapcsolódás a feladat számához a nyomonkövetési rendszerben. Példa: feature/PROJ-42-add-login.
• feature/típus/név „ kibővített formátum a feladat típusának megadásával. Példa: feature/feat/analytics-dashboard.

A feladat ID használata JIRA-ból, Trello-ból vagy más rendszerből a legjobb gyakorlat. Automatikusan összekapcsolja a kódot a feladattal, és leegyszerűsíti az ágak keresését a git log segítségével.

Pull Request folyamat

Pull Request (vagy Merge Request a GitLab-ben) „ egy kérelem a feature ág develop-ba egyesítésére. A PR nem csupán egy technikai művelet, hanem egy csapat szintű kód felülvizsgálati folyamat, amely javítja a kód minőségét és terjeszti a tudást a csapaton belül.

Egy jó PR tartalmaz egy címet a feladat rövid leírásával, egy linket a tickethez és a változtatások leírását. A fejlesztőnek jeleznie kell, hogy pontosan mi történt, mely fájlok változtak meg, és vannak-e potenciális kockázatok a projekt más részei számára.

A csapat átnézi a kódot a PR-ben, megjegyzéseket hagy, változtatásokat kér (change requests) és jóváhagyja az egyesítést (approve). A jóváhagyás után merge vagy squash merge történik.

A PR átlagos átfutási ideje a mobilfejlesztésben 4-24 óra. A Danger könyvtár automatizálja az ellenőrzések egy részét, lintereket és teszteket futtatva közvetlenül a PR-ben.

Javaslatok egy jó PR létrehozásához

• Méret „ ne legyen több 300-400 sornyi változtatásnál. A nagy PR-eket nehéz átnézni, az ellenőrzés minősége romlik.
• Egy PR „ egy feladat „ kerülje a nem kapcsolódó változtatások keverését egy kérelemben.
• Képernyőképek „ UI-változtatásokhoz csatoljon képernyőképeket előtte és utána.
• Tesztek „ az új funkcionalitáshoz írjon egységteszteket és foglalja bele azokat a PR-be.

Feature ágak egyesítési stratégiái

A PR jóváhagyása után a feature ág különböző módokon egyesíthető a develop-ba. Az egyesítési stratégia megválasztása befolyásolja a commit történetet és a változtatások visszaállításának lehetőségét.

• Merge commit „ létrehoz egy egyesítési commitot, megtartva a feature ág teljes commit történetét. A történet teljes marad, de az elágazási gráf bonyolultabbá válik.
• Squash merge „ a feature ág összes commitját egyesíti egybe, és hozzáadja a develop tetejére. A történet tisztább lesz, de a köztes commitok információi elvesznek.
• Rebase and merge „ átírja a feature ág commitjait a develop legutolsó commitja tetejére, és egyesít további commit nélkül. A történet lineáris marad.

Gyakori kiadásokkal rendelkező mobil projekteknél leggyakrabban a squash merge-t használják: tiszta történetet ad a develop-ban, míg a fejlesztés részletei a PR leírásában és a tracker feladatban maradnak.

Gyakori hibák a Feature Branch használatakor

Még tapasztalt fejlesztők is követnek el hibákat a feature ágak használatakor. A tipikus problémák ismerete segít elkerülni az idő- és adatvesztést.

• Túl hosszú ág élettartam „ a feature ág 2-3 hétnél tovább él a develop-pal való szinkronizálás nélkül, ami hatalmas egyesítési konfliktusokhoz vezet.
• Nem egyértelmű leírású commitek „ az olyan üzenetek, mint „fix” vagy „update” nem teszik egyértelművé, hogy mi változott és miért.
• Feladatok keverése „ egy feature ágban két nem kapcsolódó funkció fejlesztése zajlik, ami lehetetlenné teszi a szelektív visszaállítást.
• Szinkronizálás hiánya „ a fejlesztő nem végez git fetch-et és nem frissíti a develop-ot, ami miatt a végső merge-nél konfliktusok keletkeznek.

A legjobb módja e problémák elkerülésének, ha a projekt elején megállapodunk a munkaszabályokban és automatikus ellenőrzéseket használunk a CI/CD pipeline-ban.

Példák parancsokra a Feature Branch-hez

Tekintsünk egy gyakorlati forgatókönyvet: egy fejlesztő egy új hitelesítési funkciót kezd el egy mobil alkalmazásban. Létrehoz egy feature ágat, dolgozik a kódon, és befejezi a feladatot egy Pull Request segítségével.

# Develop frissítése és feature ág létrehozása
git checkout develop
git pull origin develop
git checkout -b feature/add-login-screen

# Munka a funkción: commitek
git add src/ui/login/
git commit -m "Add login screen layout"

# Feature ág küldése a szerverre
git push origin feature/add-login-screen

# Szinkronizálás a develop-pal (rebase)
git fetch origin develop
git rebase origin/develop

# PR jóváhagyása után: helyi develop frissítése és ág törlése
git checkout develop
git pull origin develop
git branch -d feature/add-login-screen

A git branch -d parancs csak azután törli az ágat, hogy a változtatásai teljesen egyesítésre kerültek. Ha az ág nincs egyesítve, a Git a git branch -D használatát javasolja a kényszerített törléshez „ ezt a jelzőt óvatosan használja.

Ellenőrzések automatizálása a feature ágban

A CI/CD pipeline-nak minden feature ághoz el kell indulnia a PR létrehozása előtt. Ez lehetővé teszi a problémák korai szakaszban történő felismerését, mielőtt a kód más fejlesztők felülvizsgálatára kerülne.

# GitHub Actions a feature ág ellenőrzéséhez
name: Feature Branch CI

on:
  push:
    branches:
      - 'feature/**'

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Run tests
        run: ./gradlew test
      - name: Lint check
        run: ./gradlew lint

A pipeline ellenőrzi, hogy a kód fordul-e, a tesztek átmennek-e, és a kódstílus megfelel-e a csapat által elfogadott szabványoknak. Csak az összes ellenőrzés sikeres teljesítése után hozható létre Pull Request.