Välj en grenstrategi

En grenstrategi är en regel för samarbete, inte bara namngivning. Välj den utifrån hur ofta ni gör releaser, teamets storlek, automatiska tester och hur länge ändringar kan vara isolerade. Oavsett modell behöver ni veta vilken gren som är skyddad, hur granskning går till och hur en driftsatt version identifieras.

Jämför vanliga strategier

Strategi	Grundidé	Passar särskilt	Nackdel att planera för
Korta feature-grenar / GitHub Flow	Skapa från main, granska, slå ihop och leverera	Små team och kontinuerlig leverans	Långlivade grenar ger fler konflikter
Trunk-based development	Integrera mycket små ändringar ofta	Team med snabba tester och feature flags	Kräver kontroll över ofärdiga funktioner
GitFlow	Separata långlivade utvecklings- och releasegrenar	Flera samtidiga versioner eller styrda releasefönster	Fler merges och större samordningskostnad

Standardrekommendation: korta grenar, pull requests och en skyddad main. Skapa inte en komplicerad struktur utan ett verkligt releasebehov. Ett livespel som uppdateras varje vecka kan behöva andra kontrollpunkter än ett system med flera kundversioner.

Dela större funktioner med feature flags

Feature-grenar skyddar mot ogranskad kod men löser inte nackdelarna med veckor av avvikande historik. Större funktioner kan delas upp i mindre, testade delar bakom en avstängd feature flag. Då kan kod integreras ofta utan att spelarna får en ofärdig funktion.

Binära filer och spelutveckling

Git fungerar särskilt bra för textbaserade filer som C#, C++, Markdown och konfiguration. Stora binära resurser är svårare att slå ihop. Använd Git LFS där det passar och dokumentera begränsningar för lagring och låsning. Om ni använder Perforce för stora speltillgångar måste ni definiera vilket system som är auktoritativt. Låt inte samma tillgång redigeras separat i två system utan en tydlig synkroniseringspolicy.

Dokumentera teamets regler

Grenstrategi och integrationsmetod är separata val. Jämför merge-commit, squash och rebase innan teamets merge-policy bestäms.

Ange namngivning, ärendekoppling, obligatoriska tester, granskning, merge-metod, release-taggar och rollback. En strategi är bra när hela teamet kan följa den utan att riskera viktig historik.

Fortsätt med feature-grenar, från ärende till release och Gits arbetsflöden.

Grennamn: main används som exempel. Använd master eller projektets verkliga standardgren där det behövs. Se Git-begrepp.