GitHub Flow

GitHub Flow

Ett workflow för git + GitHub

Vad är GitHub Flow?

"En lightweight, branch-baserad workflow som bygger på att main-branchen alltid ska vara deploybar"
  • Skapad av GitHub 2011 av Scott Chacon
  • Designad för team som deployar ofta
  • Filosofi: "Ship early, ship often"


OBS!!! GitHub Flow != Git Flow!

"Problem" som GH flow adresserar

  • Komplexa branching-strategier
  • Långlivade feature branches
  • Merge hell och konflikter
  • Långsamma release-cykler

GitHub Flow

Feature Branch
→
Pull Request
→
Main Branch
  • Enkel: (endast) en 'långlivad' branch (main)
  • Transparent: Pull Requests (PR)
  • Kvalitet: Code Reviews
  • Snabbt: idé till produktion

GitHub Flow vs Git Flow

Aspekt Git Flow GitHub Flow
Komplexitet Hög (5+ olika branches) Låg (feature + main)
Release-cykel Planerade releases Kontinuerlig deployment
Branch-livslängd Veckor/månader Dagar/veckor
Lämplig för Stora team, planerade releaser Agila team, web-appar

GitHub Flow vs Git Flow

"Git Flow - kraftfull men komplex."
"GitHub Flow - enkel men effektiv."

När lämpar sig GitHub Flow?

Bra för:

  • Webb-applikationer
  • Mindre team (2-10st)
  • API:er & microservices
  • Open source-projekt

Mindre bra:

  • Native desktop/mobil
  • Embedded systems
  • Enterprise/stora-system med fasta release-cykler

GitHub + GitHub Flow = true

"GitHub själva använder GitHub Flow för github.com
- 15+ deploys per dag"

...och många andra

github.blog/developer-skills
"Nu har vi en bakgrund.
Vi fortsätter med de sex kärnprinciperna
som GitHub Flow baseras på..."

De 6 Principerna

"Kärnprinciper" i GitHub Flow

1 - Main är deploybar
2 - Feature-branches
3 - Commit early, commit often
4 - Öppna PR
5 - Code Review
6 - Merge & Deploy

1. main alltid "deploybar"

för produktion

main
→
production
  • All kod - ska vara testad och reviewed
  • Inget trasigt - inga experiment på main

Detta är den viktigaste regeln!

2. Arbeta med ny funkonalitet på (nya) feature branches

main
→
feature/user-auth
$ git checkout main
$ git pull origin main
$ git checkout -b feature/user-auth

2.1 Använd "bra" och tydliga namn på feature branches

Ok:

  • feature/user-login
  • feature/db-conn
  • hotfix/security-patch
  • improvement/api-performance

Njae:

  • efo-leker-ø
  • 13saft37
  • test123
  • new-stuff

3. Commit early, commit often

1
2
3
4

Tumregel: Små, atomära commits

- Gör en överenskommelse i teamet - hur ofta och när.
- Använd koncisa och tydliga commit messages.

Ok:

  • Added user auth endpoint
  • Removed null value in user auth token
  • Refactor db model

Nej!:

  • fixed stuff
  • updates
  • måste på toa /mvh efo
  • as3dfghj

2. Öppna Pull Request

Gör tydliga och beskrivande PR.
Gärna med beskrivande text över innehållet.

Exempel PR:

Titel/Ämne: Added user auth

Beskrivning: JWT-baserad auth för API

Ändringar:

  • Ny AuthController med login/logout endpoints
  • JWT token generation och validering
  • Middleware för att skydda routes
  • xyz...

Öppna gärna PR tidigt - vänta inte för länge

  • Feedback tidigt - innan för mycket ändringar gjorts
  • Diskussion i teamet - finns andra, bättre lösningar?
  • Transparens - alla (teamet) blir uppdaterade och är med i vad som händer
  • Ur ett CI-perspektiv - bra om problem upptäcks i ett tidigt skede

5. Code Review & Diskussion

Vad ska granskas/diskuteras för ett PR?

Bestäms av teamet, men förslagsvis:
Kod-kvalitet:
  • Läsbarhet och struktur
  • Sårbarheter, prestanda etc
  • Kodstandarder
Funktionalitet:
  • Löses rätt problem?
  • Om tester - tillräckliga?
  • Ev. dokumentation uppdaterad?

forts 5. Code Review & Diskussion


Kom överens i teamet om när ett PR kan/ska godkännas/"merge:as".

Tips: gör en checklista med punkter som ska uppfyllas för när ett PR kan mergas.

t ex, se föregående slide

minst 2 ok => PR ok

6. Merge och Deploy

När ett PR är klart så är tanken att ev builds och tester görs för att sedan deploy/driftsättas och nya features går "live".

Teamet bör också se till att hämta senaste ändringarna från main;

$ git checkout main
$ git pull origin main

6. forts. Merge och Deploy

I den bästa av världar har vi nu CI/CD pipelines

  • CI/CD pipelines som körs automatiskt efter merge
  • Tester som validerar att allt fungerar
  • Rollback-möjlighet om något går fel

Summering GitHub Flow

main
alltid deploybar
↓
feature/new-login
feature branches
↓
1
2
3
commits, push + PR

forts. Summering GitHub Flow

↓
PR + Code Review ✓
diskussion & godkännande
↓
main (uppdaterad)
→
Production

Nu ska vi leka!

Vi har sett teorin bakom GitHub Flow...

Dags för lite live-demo!

Försökspersoner: efo & msc
nästa del