Feature Branch i Git: vad det är, hur man skapar och arbetar med grenar

Vad är Feature Branch i Git

Feature Branch (funktionsgren) “ är en tillfällig gren i Git, skapad från develop för att utveckla en separat funktionalitet. Till skillnad från de långlivade grenarna main och develop, existerar feature-grenar under begränsad tid “ från några timmar till några veckor.

Huvudsyftet med feature branch är att isolera ändringar som hör till en uppgift från resten av koden. Utvecklaren kan experimentera, göra många commits och till och med förstöra koden i sin gren utan att påverka andra teammedlemmars arbete.

Efter att utvecklingen är klar slås feature-grenen tillbaka till develop via Pull Request med obligatorisk kodgranskning. Efter sammanslagningen tas grenen vanligtvis bort för att hålla repositoryt rent.

Enligt Vincent Driessen, 2010 har Git Flow-modellen med feature-grenar blivit industristandard tack vare den tydliga ansvarsfördelningen mellan olika grentyper.

Arbetsflöde med Feature Branch

Arbetsflöde med feature branch består av en sekvens steg som utvecklaren utför för varje ny funktion. Denna process minimerar sammanslagningskonflikter och säkerställer kvalitetskontroll av koden.

1. Skapa gren från develop senaste commit. Utvecklaren växlar till develop, uppdaterar den och skapar en ny feature-gren.
2. Utveckling och commits i feature-grenen. Utvecklaren gör ändringar, gör commits med tydliga beskrivningar och pushar regelbundet grenen till fjärrrepositoryt.
3. Synkronisering med develop “ under utvecklingen kan huvudgrenen gå framåt. Utvecklaren utför rebase eller merge develop i sin feature-gren.
4. Skapa Pull Request “ när funktionen är klar öppnar utvecklaren en PR för kodgranskning. Teamet granskar koden och lämnar kommentarer.
5. Sammanslagning och borttagning “ efter PR-godkännande slås grenen samman med develop och tas bort både lokalt och fjärranslutet.

Periodisk synkronisering med develop är av avgörande betydelse. Ju längre en feature-gren lever utan att slå samman ändringar från develop, desto högre är sannolikheten för konflikter vid den slutliga sammanslagningen.

Synkroniseringsfrekvens för feature-gren

Namnregler för feature-grenar

Namngivning av grenar “ en viktig del av teamdisciplin. En enhetlig namngivningsstandard gör att snabbt kunna avgöra vilken uppgift som arbetas på och vem som utför den.

• feature/namn “ prefixet feature/ används i klassisk Git Flow. Exempel: feature/added-auth-module.
• feature/JIRA-123-beskrivning “ koppling till uppgiftsnumret i spårningssystemet. Exempel: feature/PROJ-42-add-login.
• feature/typ/namn “ utökat format med angivelse av uppgiftstyp. Exempel: feature/feat/analytics-dashboard.

Att använda uppgifts-ID från JIRA, Trello eller annat system är bästa praxis. Det kopplar automatiskt ihop koden med uppgiften och förenklar sökning efter grenar via git log.

Pull Request-process

Pull Request (eller Merge Request i GitLab) “ är en begäran om att slå samman feature-grenen med develop. PR är inte bara en teknisk operation, utan en process för teamets kodgranskning som förbättrar kodkvaliteten och sprider kunskap inom teamet.

En bra PR innehåller en rubrik med en kort uppgiftsbeskrivning, en länk till ärendet och en beskrivning av ändringarna. Utvecklaren bör ange exakt vad som gjorts, vilka filer som ändrats och om det finns potentiella risker för andra delar av projektet.

Teamet granskar koden i PR, lämnar kommentarer, begär ändringar (change requests) och godkänner sammanslagningen (approve). Efter godkännande utförs merge eller squash merge.

Genomsnittlig granskningstid för PR i mobil utveckling är 4 till 24 timmar. Biblioteket Danger automatiserar en del av kontrollerna genom att köra linters och tester direkt i PR.

Rekommendationer för att skapa en bra PR

• Storlek “ inte mer än 300-400 rader ändringar. Stora PR är svåra att granska, granskningskvaliteten minskar.
• En PR “ en uppgift “ undvik att blanda orelaterade ändringar i en begäran.
• Skärmdumpar “ för UI-ändringar, bifoga skärmdumpar före och efter.
• Tester “ för ny funktionalitet, skriv enhetstester och inkludera dem i PR.

Sammanslagningsstrategier för feature-grenar

Efter PR-godkännande kan feature-grenen slås samman med develop på olika sätt. Valet av sammanslagningsstrategi påverkar commit-historiken och möjligheten att återställa ändringar.

• Merge commit “ skapar en sammanslagningscommit, och bevarar hela commit-historiken för feature-grenen. Historiken förblir komplett men förgreningsgrafen blir mer komplex.
• Squash merge “ slår ihop alla commits från feature-grenen till en och lägger till den ovanpå develop. Historiken blir renare, men information om mellanliggande commits går förlorad.
• Rebase and merge “ skriver om commits från feature-grenen ovanpå den senaste develop-committen och slår samman utan extra commit. Historiken förblir linjär.

För mobilprojekt med frekventa utgåvor används oftast squash merge: det ger en ren historik i develop, medan utvecklingsdetaljer finns kvar i PR-beskrivningen och tracker-uppgiften.

Vanliga misstag vid arbete med Feature Branch

Även erfarna utvecklare gör misstag när de arbetar med feature-grenar. Kännedom om typiska problem hjälper till att undvika förlust av tid och data.

• För lång livslängd på grenen “ feature-grenen lever längre än 2-3 veckor utan synkronisering med develop, vilket leder till massiva sammanslagningskonflikter.
• Commits med otydliga beskrivningar “ meddelanden som “fix” eller “update” förtydligar inte vad som ändrats och varför.
• Blandning av uppgifter “ i en feature-gren utvecklas två orelaterade funktioner, vilket gör selektiv återställning omöjlig.
• Brist på synkronisering “ utvecklaren gör inte git fetch och uppdaterar inte develop, vilket orsakar konflikter vid den slutliga merge.

Det bästa sättet att undvika dessa problem är att komma överens om arbetsregler i början av projektet och använda automatiska kontroller i CI/CD-pipelinen.

Exempel på kommandon för Feature Branch

Låt oss överväga ett praktiskt scenario: en utvecklare påbörjar en ny autentiseringsfunktion i en mobilapp. Han skapar en feature-gren, arbetar på koden och slutför uppgiften med en Pull Request.

# Uppdatera develop och skapa feature-gren
git checkout develop
git pull origin develop
git checkout -b feature/add-login-screen

# Arbeta med funktionen: commits
git add src/ui/login/
git commit -m "Add login screen layout"

# Skicka feature-grenen till servern
git push origin feature/add-login-screen

# Synkronisering med develop (rebase)
git fetch origin develop
git rebase origin/develop

# Efter PR-godkännande: uppdatera lokal develop och ta bort grenen
git checkout develop
git pull origin develop
git branch -d feature/add-login-screen

Kommandot git branch -d tar bort grenen först efter att dess ändringar har slagits samman fullständigt. Om grenen inte är sammanslagen kommer Git att föreslå att använda git branch -D för tvångsborttagning “ använd denna flagga med försiktighet.

Automatisering av kontroller i feature-grenen

CI/CD-pipelinen bör köras för varje feature-gren innan en PR skapas. Detta gör det möjligt att upptäcka problem i ett tidigt skede, innan koden når granskning av andra utvecklare.

# GitHub Actions för kontroll av feature-gren
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

Pipelinen kontrollerar att koden kompileras, testerna går igenom och kodstilen följer de standarder som teamet antagit. Först efter att alla kontroller har godkänts kan en Pull Request skapas.