Develop Branch i Git — vad det är, syfte och funktionsprincip

Vad är Develop Branch i Git

Develop Branch (utvecklingsgren) — en långlivad gren i Git Flow som fungerar som en central nod för integration av kod från alla utvecklare. Feature-grenar slås samman i den efter slutförd utveckling och godkänd code review.

Kod i develop är alltid i ett tillstånd redo för att skapa en release, även om den ännu inte har publicerats i produktion. Detta innebär att alla funktioner i develop har genomgått review, testning och integrationskontroller, men väntar fortfarande på sin releasecykel.

Till skillnad från main, där varje kodversion är en release, innehåller develop en kontinuerlig ström av ändringar. Commits i develop dyker upp allt eftersom feature-grenar slås samman, vilket kan ske flera gånger om dagen.

Enligt data från Vincent Driessen, 2010 är develop ett nyckelelement i en framgångsrik branch-modell, eftersom den separerar pågående arbete från versioner redo för release.

Skillnader mellan develop och main branch

Att förstå skillnaderna mellan develop och main är avgörande för korrekt arbete i Git Flow. Dessa grenar utför olika funktioner och har olika stabilitetskrav.

Uppdelningen i develop och main gör att teamet kontinuerligt kan integrera ny kod utan att riskera stabiliteten i produktionsversionen. Utvecklare kan se sin kod i develop direkt efter godkännande av PR, även före den officiella releasen.

Develops roll i Git Flow

I Git Flow-modellen intar develop en central plats mellan feature-grenar (källa för ändringar) och release-grenar (förberedelse för lansering). Att förstå denna hierarki är grunden för effektiv branching.

• Feature → Develop — varje slutförd funktion slås samman i develop via en Pull Request med code review.
• Develop → Release — när tillräckligt med ändringar har samlats för en release skapas release-grenen från develop.
• Release → Main + Develop — efter slutlig förberedelse slås release-grenen samman i main (release) och tillbaka i develop (buggfixar).
• Hotfix → Main + Develop — kritiska korrigeringar skapas från main och slås samman i båda grenarna.

En sådan struktur garanterar att develop alltid innehåller den senaste kodversionen med alla nya funktioner, och main — endast verifierad produktionskod. Detta är särskilt viktigt för mobila projekt med lång granskningscykel i App Store och Google Play.

Develops relation till andra Git Flow-grenar

Develop fungerar som en central länk mellan feature-, release- och hotfix-grenar. Att förstå sammanfogningsriktningarna är grunden för att förebygga konflikter och förlust av commits.

Kvalitetskrav för kod i develop

Kodkvalitet i develop måste vara hög, men inte absolut. Till skillnad från main, där varje fel innebär en brådskande hotfix, tillåter develop mindre brister som kommer att åtgärdas före releasen.

Minimikrav för kod före sammanfogning i develop:

• Kompilering — koden måste kompileras utan fel. En trasig kompilering i develop blockerar hela teamets arbete.
• Enhetstester — alla befintliga tester måste godkännas. Ny kod måste ha minst 70% testtäckning.
• Code style — koden måste följa de format- och namnstandarder som accepterats i teamet.
• Inga föråldrade API:er — användning av föråldrade metoder är inte tillåten i ny kod.

Automatiska kontroller i CI/CD-pipelinen måste köras vid varje push till develop. Om kompileringen går sönder måste den ansvariga utvecklaren åtgärda problemet inom en timme eller återställa sin commit.

CI/CD-kontroller för develop

Konfiguration av GitHub Actions för develop garanterar att varje PR före sammanfogning genomgår automatisk kontroll. En typisk pipeline inkluderar kompilering, tester och linting.

# GitHub Actions — kontroll av develop efter sammanfogning
name: Develop CI

on:
  pull_request:
    branches: [develop]

jobs:
  validate:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Unit tests
        run: ./gradlew testDebug
      - name: Lint
        run: ./gradlew lint
      - name: Build
        run: ./gradlew assembleDebug

Regler för sammanfogning i develop

Sammanfogning i develop måste följa strikta regler för att upprätthålla stabiliteten i integrationsgrenen. Brott mot dessa regler leder till konflikter, trasiga kompileringar och slöseri med teamets tid.

• Endast via Pull Request — direkt push till develop är förbjuden. Alla ändringar går igenom code review.
• Minst ett godkännande — PR måste godkännas av minst en utvecklare som inte deltog i uppgiften.
• Squash merge — det rekommenderas att slå ihop alla commits från feature-grenen till en vid sammanfogning i develop för en ren historik.
• PR:s aktualitet — före sammanfogning måste PR uppdateras i förhållande till den senaste commiten i develop (rebase eller merge).

Regeln om PR:s aktualitet är särskilt viktig. Om feature-grenen skapades för en vecka sedan och develop har gått 50 commits framåt, kan direkt sammanfogning leda till konflikter som bättre löses i PR:s sammanhang, inte i develop.

Skydd av develop från felaktiga sammanfogningar

Branch protection rules (grenskyddsregler) — inställningar på GitHub-, GitLab- eller Bitbucket-nivå som förhindrar felaktiga ändringar i develop. De garanterar att även en oavsiktlig push inte bryter integrationsgrenen.

Rekommenderade skyddsregler för develop:

• Require pull request — förbjud direkt push till develop. Alla ändringar endast via PR.
• Require approvals — minst 1-2 godkännanden före sammanfogning av PR.
• Require status checks — blockera sammanfogning om CI/CD-pipelinen inte har godkänts.
• Require up-to-date — PR-grenen måste uppdateras i förhållande till develop före sammanfogning.
• Restrict push access — begränsa push-rättigheter till develop endast för seniora utvecklare.

Att konfigurera develop-skydd tar 10 minuter, men förhindrar veckor av stillestånd relaterade till en trasig integrationsgren. För mobila projekt med multiplattformsteam är detta särskilt relevant.

Exempel på kommandon för att arbeta med develop

Låt oss titta på en typisk dag för en utvecklare: på morgonen uppdaterar han develop, skapar en ny feature-gren, och efter slutförandet av uppgiften slår han samman ändringarna tillbaka till develop.

# Morgonsynkronisering av develop
git checkout develop
git pull origin develop

# Skapa ny feature-gren från develop
git checkout -b feature/add-push-notifications

# Arbeta med funktion...
git add . && git commit -m "Add FCM integration"

# Uppdatera develop under utveckling
git fetch origin develop
git rebase origin/develop

# Efter godkännande av PR — uppdatera lokal develop
git checkout develop
git pull origin develop
git branch -d feature/add-push-notifications

Kommandot git pull i develop utför två operationer samtidigt: git fetch (hämtar nya commits från servern) och git merge (slår samman dem med den lokala grenen). För develop är detta standardsättet för synkronisering.

Återställning av develop efter trasig sammanfogning

Om kod som bröt kompileringen kom in i develop måste man agera snabbt. Varje timmes stillestånd för develop innebär blockerat arbete för hela utvecklarteamet.

Om kod som bröt kompileringen kom in i develop, använd git revert för att skapa en ny commit som ångrar de problematiska ändringarna. Använd inte git reset i develop — detta skriver om historiken som redan finns hos andra deltagare.

# Hitta problematisk commit
git log --oneline develop

# Ångra commit via revert (säkert)
git revert a1b2c3d

# Skicka korrigering till fjärr-develop
git push origin develop

# Visa ändringar i en specifik commit
git show a1b2c3d --stat