Release Branch i Git — vad det är, syfte och arbetsprocess

Vad är Release Branch i Git

Release Branch (releasgren) — är en tillfällig gren i Git Flow, skapad från develop när teamet bestämmer att den aktuella funktionsuppsättningen är redo för lansering. Den finns precis så länge som den slutliga förberedelsen av releasen pågår — från några timmar till några dagar.

Huvudsyftet med releasgrenen — att frysa en specifik funktionsuppsättning för releasen utan att stoppa utvecklingen av nästa versioner. Medan releasgrenen förbereds för lansering kan andra utvecklare fortsätta att slå samman feature-grenar i develop för nästa release.

I releasgrenen skapas inga nya funktioner — endast buggfixar, uppdatering av applikationsversion, lokalisering och dokumentation. Efter att allt arbete är slutfört slås releasgrenen samman i main (markeras som release) och tillbaka i develop (så att buggfixarna når framtida versioner).

Enligt Atlassian, 2024, är releasgrenar kritiskt viktiga för projekt med regelbundna releasescykler — de säkerställer förutsägbarhet och stabilitet i lanseringsprocessen.

Livscykeln för en releasgren

Livscykeln för en releasgren från skapande till borttagning omfattar flera steg. Att förstå varje steg hjälper teamet att synkronisera åtgärder och undvika misstag.

1. Skapande — från den senaste commiten i develop skapas en gren med namnet release/2.5.0. develop fortsätter att ta emot feature-grenar för nästa version.
2. Förberedelse — i releasgrenen uppdateras applikationsversionen i build.gradle, Info.plist och andra konfigurationsfiler.
3. Buggfixning — kritiska buggar som hittats under sluttestningen åtgärdas. Endast buggar — inga nya funktioner.
4. Sluttestning — QA-teamet utför regressionstestning på releasgrenen. Nya buggar skickas för åtgärd i samma gren.
5. Sammanslagning i main — releasgrenen slås samman i main med flaggan --no-ff. En releasetagg skapas: v2.5.0.
6. Sammanslagning i develop — releasgrenen slås tillbaka i develop, så att buggfixarna från releasen når den aktuella utvecklingen.
7. Borttagning — releasgrenen tas bort lokalt och på distans, eftersom dess uppgift är slutförd.

Punkt 6 — återföring till develop — glöms ofta bort, men är kritisk. Utan den kommer buggfixar som gjorts i release inte in i develop, och i nästa release kan samma fel uppträda igen.

Typiska tidslängder för releasgrenens steg

Releasgrenens livslängd beror på releasens komplexitet och kodkvaliteten i develop. I genomsnitt tar förberedelsen 2 till 5 arbetsdagar för en medelstor mobilapplikation.

Vad görs i releasgrenen

I releasgrenen utförs en strikt begränsad uppsättning uppgifter. Varje avvikelse från denna lista bryter mot Git Flow-modellen och skapar risker för releasens stabilitet.

Regeln om förbud mot nya funktioner — den viktigaste i releasgrenen. Om en funktion inte hann till releasen väntar den på nästa cykel. Försök att pressa in en oavslutad funktion i releasgrenen — den främsta orsaken till deadlineförseningar och buggar i produktion.

Uppdatering av version i ett mobilt projekt

I releasgrenen uppdateras obligatoriskt applikationens versionsnummer. För Android är detta fälten versionCode och versionName i build.gradle, för iOS — CFBundleShortVersionString i Info.plist.

// build.gradle (app-nivå) — versionsuppdatering i releasgrenen
android {
    defaultConfig {
        versionCode 42
        versionName "2.5.0"
    }
}

// För iOS — uppdatering av Info.plist
// CFBundleShortVersionString = 2.5.0
// CFBundleVersion = 42

Skillnader mellan release och hotfix

Nybörjarutvecklare blandar ofta ihop release och hotfix-grenar, även om deras syfte är fundamentalt olika. Ett misstag vid val av grenyp kan leda till försening av en kritisk korrigering eller störning av releasesprocessen.

• Källa — release skapas från develop, hotfix — från main. Detta är den huvudsakliga skillnaden som bestämmer allt annat.
• Brådskande — release är planerad: teamet bestämmer själv när förberedelsen ska påbörjas. Hotfix är akut: ett problem i produktion kräver omedelbar åtgärd.
• Innehåll — release kan innehålla flera korrigeringar och versionsuppdatering. Hotfix innehåller endast en kritisk korrigering.
• Sammanslagning — release slås samman i main och develop. Hotfix slås också samman i main och develop, men prioriterat.
• Livslängd — release lever 1 till 7 dagar. Hotfix lever 30 minuter till 1 dag.

Om en bugg upptäcks under releaseförberedelsen (i releasgrenen) — är det en vanlig buggfix. Om en bugg upptäcks i produktion (på main) — är det en hotfix, och den skapas från main, även om releasgrenen redan finns.

Namngivningsregler för releasgrenar

En enhetlig standard för namngivning av releasgrenar förenklar navigeringen i arkivet och gör att CI/CD-system automatiskt kan avgöra att grenen tillhör releasesprocessen.

• release/X.Y.Z — standardformat för Git Flow, där X.Y.Z är releaseversionen. Exempel: release/2.5.0.
• release/namn — alternativt format med kodnamn för releasen. Exempel: release/merlin.
• release/datum — format med releasedatum. Används sällan eftersom version är viktigare än datum. Exempel: release/2024-12-01.

Formatet release/X.Y.Z — föredras eftersom det explicit kopplar grenen till det versionsnummer som kommer att tilldelas releasen. Detta förenklar sökning och automatisk bearbetning av CI/CD-skript.

Strategi för återföring till develop

Återföring (merge back) av releasgrenen till develop — en av de viktigaste och samtidigt ofta förbisedda operationerna. Utan den förblir alla buggfixar som gjorts i release endast i releaseversionen och kommer inte in i nästa releasescykel.

Återföringsprocessen utförs efter att releasgrenen redan har slagits samman i main. Först slås release samman i develop, sedan — tas bort. Detta garanterar att develop innehåller alla korrigeringar som gjorts under releaseförberedelsen.

Efter återföring är konflikter möjliga — särskilt om nya feature-grenar som ändrat samma filer redan har dykt upp i develop. Utvecklaren som ansvarar för releasen löser dessa konflikter och pushar develop till servern.

Vissa team använder rebase istället för merge för återföring, så att historiken förblir linjär. Merge är dock säkrare för develop eftersom det inte skriver om commithistorik som redan kan ha använts av andra utvecklare.

Exempel på kommandon för att arbeta med release

Låt oss titta på den fullständiga arbetscykeln med releasgrenen: från skapande till borttagning efter en framgångsrik release av mobilapplikationen version 2.5.0.

# 1. Skapa releasgren från develop
git checkout develop
git pull origin develop
git checkout -b release/2.5.0

# 2. Versionsuppdatering och buggfixar
git add build.gradle
git commit -m "Bump version to 2.5.0"

# 3. Åtgärda buggar (endast bugfixes)
git add src/fix/
git commit -m "Fix crash on payment screen"

# 4. Skicka releasgrenen till servern
git push origin release/2.5.0

# 5. Sammanslagning av release i main
git checkout main
git pull origin main
git merge --no-ff release/2.5.0
git tag -a v2.5.0 -m "Release 2.5.0"
git push origin main --tags

# 6. Återföring till develop
git checkout develop
git merge --no-ff release/2.5.0
git push origin develop

# 7. Ta bort releasgrenen
git branch -d release/2.5.0
git push origin --delete release/2.5.0

Kommandona 5 och 6 — dubbel sammanslagning — är kritiskt viktiga. Först får main releaseskoden och taggen, sedan synkroniseras develop med buggfixarna från release. Om steg 6 hoppas över kommer korrigeringarna från releasen inte in i nästa utvecklingscykel.

Automatisering av releasesprocessen

För mobila projekt med regelbundna releaser kan processen att skapa en releasgren och uppdatera versionen automatiseras via CI/CD-skript. GitHub Actions gör det möjligt att skapa ett workflow som vid knapptryckning skapar en releasgren med automatisk versionsuppdatering.

För mobila projekt med regelbundna releaser kan processen att skapa en releasgren och uppdatera versionen automatiseras via CI/CD-skript. GitHub Actions gör det möjligt att skapa ett workflow som vid knapptryckning skapar en releasgren med automatisk versionsuppdatering.

# GitHub Actions — automatisering av skapande av releasgren
name: Create Release Branch

on:
  workflow_dispatch:
    inputs:
      version:
        description: 'Release version (e.g. 2.5.0)'
        required: true

jobs:
  create-release:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Create release branch
        run: |
          git checkout develop
          git checkout -b release/${{ inputs.version }}
          git push origin release/${{ inputs.version }}