Github Flow

GitHub Flow er en populær arbejdsgang blandt softwareudviklere, der bruger Git og GitHub til versionskontrol. Den er designet til at være enkel, men effektiv, og understøtter kontinuerlig integration af nye funktioner, rettelser og opdateringer. Dette sikrer, at softwareprojekter kan udvikle sig hurtigt og sikkert med minimal risiko for konflikter eller fejl i produktionsmiljøet.

Clone

I hjertet af GitHub Flow ligger ideen om “cloning”, hvor udviklere kopierer et eksisterende Git-repository til deres lokale maskine. Dette giver dem friheden til at eksperimentere og udvikle uden at påvirke hovedrepository’et. Når du klone et repository, bringer du en øjeblikkelig kopi af alle filer og den komplette versionshistorik ned til din egen computer, hvilket giver et solidt fundament at bygge videre på.

Branches

Traditionelt har mange Git-baserede projekter anvendt en “master” branch som hovedlinjen for produktionsklar kode. Dertil kommer ofte en “develop” branch, hvor al ny udvikling samles inden den når “master”. Dette skel mellem “master” og “develop” hjælper med at holde stabil kode adskilt fra nyudviklede funktioner og rettelser, der endnu ikke er helt klar til at blive rullet ud i produktion.

Udvikling af nye funktioner og rettelser foregår i dedikerede branches, typisk kaldet “feature” eller “hotfix” branches. En “feature” branch bruges til at udvikle nye funktioner, mens en “hotfix” branch bruges til hurtige rettelser af kritiske fejl i den allerede udrullede software. Ved at isolere disse ændringer i separate branches, kan udviklere arbejde parallelt uden at forstyrre hinanden eller den overordnede kodebase.

Commits

Når ændringerne i en “feature” eller “hotfix” branch er klar, bliver de fastlagt gennem “commits”. Et commit er et øjeblikssnapshot af din kode, som dokumenterer præcis, hvad der er ændret, og hvorfor. Dette bygger en historik af ændringer, som både er nyttig for at forstå projektets udvikling og for at rulle tilbage til tidligere versioner, hvis noget går galt.

For at dele disse commits med resten af teamet, bruges kommandoen “push” til at sende dem til GitHub. Dette gør det muligt for andre at se, gennemgå og bygge videre på dit arbejde.

Pull Requests

Den centrale mekanisme i GitHub Flow er “pull requests” (PR). En PR er en anmodning om at integrere dine ændringer fra en “feature” eller “hotfix” branch ind i “develop” eller “master”. Det er her, magien ved samarbejde og kvalitetssikring virkelig skinner igennem. Teammedlemmer kan gennemgå koden, diskutere potentielle forbedringer og endda tilføje yderligere ændringer, før den bliver en del af den primære kodebase.

Når en PR er godkendt, anvendes “merge” for at integrere ændringerne. Dette skaber en forenet historik af projektets udvikling og sikrer, at alle bidrag er nøje dokumenteret og gennemgået. Merge-processen er afgørende for at opretholde en sund og robust kodebase, klar til produktion.

GitHub Flow tilbyder en intuitiv og effektiv metode til softwareudvikling, der understøtter teams i deres stræben efter at udvikle høj kvalitets software hurtigt og sikkert. Ved at følge disse principper kan udviklere nemmere håndtere kompleksiteten af moderne softwareprojekter og sikre, at deres bidrag bidrager positivt til projektets overordnede mål.

Eksempel

Lad os gå igennem et eksempel på GitHub Flow med fokus på oprettelse af en ny “feature” og integrationen af denne tilbage i hovedkoden.

Forestil dig, at vi starter med en nyoprettet “master” branch. Vores mål er at udvikle en ny funktion, gennemgå den med teamet, og derefter integrere den sikker i “master” branchen.

• Start fra “master”

Vi starter med en ren “master” branch, som repræsenterer den aktuelle produktionsklare kode.

• Opret en “feature” branch

Fra “master” opretter vi en ny “feature” branch kaldet “feature/add-new-login”.

• Udvikle og committe ændringer

Udviklingen foregår i “feature/add-new-login” branchen. Når funktionen er klar, laver vi et eller flere commits.

• Push “feature” branch og opret en Pull Request (PR)

Når funktionen er klar til gennemsyn, pusher vi “feature” branchen til GitHub og opretter en PR mod “master”.

• Review, diskussion, og godkendelse af PR

Teamet gennemgår PR’en, diskuterer potentielle forbedringer, og godkender til sidst ændringerne.

• Merge PR til “master”

Med godkendelsen på plads, bliver “feature” branchen “merged” ind i “master”.

• Deploy fra “master”

Med de nye ændringer nu en del af “master”, er koden klar til at blive deployet til produktion.

graph TD;
    A[Start: Master] --> B[Opret Feature Branch];
    B --> C[Develop & Commit];
    C --> D[Push & Opret PR];
    D --> E[Review & Godkend PR];
    E --> F[Merge PR til Master];
    F --> G[Deploy fra Master];

Dette flow sikrer, at alle ændringer er gennemgået og godkendt, før de bliver en del af den primære kodebase, hvilket minimerer risikoen for fejl i produktion. Ved at bruge “feature” branches, holder vi udviklingen organiseret og isoleret fra den stabile “master”, hvilket gør det lettere at administrere flere udviklingsaktiviteter samtidigt.

Release (tags) i GitHub

Efter en vellykket merge af en Pull Request (PR) ind i “master” branchen, er næste skridt ofte at markere denne nye tilstand af koden som en officiel release. I GitHub kan dette gøres ved at anvende tags til at skabe en snapshot af koden på et givet tidspunkt, hvilket typisk svarer til en udgivelse (release) af softwaren. Dette gør det nemt at holde styr på versioner og gøre specifikke versioner tilgængelige for download eller deployment.

En release i GitHub baseres på Git tags, som er markører, der kan tilføjes til en specifik commit i historikken for at angive et vigtigt punkt, typisk en versionudgivelse. Tags kan være enten letvægts (kun et navn på en commit) eller annoterede (indeholder også metadata såsom forfatter, dato, og en besked).

Releases i GitHub giver en brugervenlig måde at distribuere software på, da de tillader udviklere og brugere at downloade bestemte versioner direkte fra GitHub. Dette er især nyttigt for projekter, der inkluderer kompilerede binære filer eller andre ressourcer, der ikke nemt kan distribueres gennem Git.

Ved at anvende tags og releases sikrer du, at dit projekt har en klar og sporbar historik af udgivelser, hvilket er afgørende for versionskontrol og samarbejde i softwareudviklingsprojekter.

Opgaver

• O290 Øvelse i Github Flow