View on GitHub

reload.github.com

Reload Pages on Github

Git the Reload! way.

Git

Er du Mac bruger, så installer Homebrew og brug brew til at installere git. Ellers se denne side for installation på andre systemer.

brew install git
      

Denne tutorial er et godt sted at starte, og hvis du skal bruge hjælp til en specifik kommando kan du altid bruge:

git help <command>  
      

git-flow

Git-flow er en wrapper til normale git kommandoer. git-flow kan med andre ord ikke mere end git. Til gengæld sparer det dig tid ved at forkorte alle de trivielle arbejdsgange i git.

Git-flow kan installeres via homebrew (hvis du er på mac). Hvis du er på andet OS kan du finde hjælp her.

brew install git-flow  
      

Få en video-introduktion her.

Du kan altid få hjælp til git-flow ved

$> git flow help
  usage: git flow <subcommand>

  Available subcommands are:
     init      Initialize a new git repo with support for the branching model.
     feature   Manage your feature branches.
     release   Manage your release branches.
     hotfix    Manage your hotfix branches.
     support   Manage your support branches.
     version   Shows version information.

  Try 'git flow <subcommand> help' for details.
      

Herunder er beskrevet visuelt hvordan branching modellen ser ud i praksis.

image
image

Branches

Hos Reload! ligger vores projekter på GitHub. Vi har 5 forskellige branch-termer vi benytter os af: feature, hotfix, release, develop og master.

Develop branch

Develop branchen kan man sige er hovedbranchen, da den er et snapshot af
ændringerne der kommer med i næste release. Når develop branchen er stabil så
er den klar til at blive released, dette sker ved at lave en release branch og
få denne tagget med versionsnummer.

Der kan være tilfælde hvor man kan lave en lille ændring direkte på develop, men ikke som udgangspunkt.
Develop branchen kan direkte benyttes til at holde kunden opdateret på
fremdrift, ved at have en test server som bliver checket ud med nyeste snapshot
af develop branchen.

Master branch

master-branchen er stable branch, og den branch der tagges med versionnummer. Det er også den branch som er findes på produktionsserveren - enten via HEAD, SHA eller specifikt tag.
master-branchen er den branch som merges ud fra når man starter en hotfix-branch.

Feature branch

En feature branch benyttes til at udvikle en ny feature til et projekt (surprise), en feature er ikke en kritisk ændring af koden, som ikke kan vente til ny release.
I git-flow-terminologien er en feature-branch blot en branch som oprettes på baggrund af develop-branchen. Når feature-branchen er klar, så pushes den til github hvor der oprettes en Pull request.

git flow feature start <feature_navn>
      

Vil give outputtet

$> git flow feature start reload-1337
  Switched to a new branch 'feature/reload-1337'

  Summary of actions:
  - A new branch 'feature/reload-1337' was created, based on 'develop'
  - You are now on branch 'feature/reload-1337'

  Now, start committing on your feature. When done, use:

   git flow feature finish reload-1337
      

Git-flow skriver altid hvad der sker når du eksekverer en kommando, så på den måde ved man også lidt om hvad der foregår af magi.

I dette tilfælde vil det altså sige, når du “starter” en feature-branch, så branches der ud fra develop, og oprettes en branch med navnet feature/<feature_navn>. <feature_navn> er blot en beskrivende tekst på engelsk for hvad er det for en feature. Vi benytter os ofte af at kalde vore features ticket navn fra Jira ticket system, evt med en kort beskrivelse ex.

Hvorved der oprettes en branch med navnet feature/RELOAD-1337

Når du vil pushe din nye feature til GitHub:

git flow feature publish <feature_navn>
      

Vil give outputtet

$ git flow feature publish reload-1337
  Total 0 (delta 0), reused 0 (delta 0)
  To git@github.com:reload/FDB-Madsite.git
   * [new branch]      feature/reload-1337 -> feature/reload-1337
  Already on 'feature/reload-1337'

  Summary of actions:
  - A new remote branch 'feature/reload-1337' was created
  - The local branch 'feature/reload-1337' was configured to track the remote branch
  - You are now on branch 'feature/reload-1337'
      

Denne kommando pusher feature-branchen til GitHub, uden at den bliver merged ind i nogen eksisterende branch.

Her afviger vi fra normal git-flow procedure.

Herefter opretter man på GitHub en Pull Request som en anden person hos Reload! skal reviewe og teste.
Når Reload! har testet og sagt god for featuren, så er næste step at få merged pull requesten ind i develop ved trykkes der på Merge Pull Request på GitHub, og GitHub merger automatisk featuren ind i develop-branchen. (Se evt Pull Requests)

Så en feature-branch afsluttes i praksis aldrig. Du skal blot selv sørge for at slette din feature-branch lokalt. Dette kunne gøres ved:

git checkout develop
  git branch -d <feature_navn>  
      

Hotfix branch

image
image

Et hotfix er en rettelse der laves direkte til master dvs. produktionsmiljøet, og benyttes kun til at rette kritiske fejl på en eksisterende løsning, som skal løses ASAP, dvs det kan ikke vente til der bliver released en ny version.
Versionsnumre der benyttes til angivelse af en hotfix er i formatet x.y.z eks. 1.3.37 hvis der har været 37 hotfixes til 1.3.

git flow hotfix start <versions-nummer>
  git flow hotfix finish <versions-nummer>
      

Sidste parameter til git flow hotfix-kommandoen er det tag/versionsnummer som master-branchens commit bliver tagget med, når hotfix-branchen bliver merged tilbage ind i master.

git push origin develop master <versions-nummer>
      

Igen for hotfix branches er det også gældende som for feature branches, nemlig at der i de fleste tilfælde bør oprettes en pull request så koden kan blive godkendt inden en endenlig ny version pushes til produktion, her skal det huskes at pull requesten skal være mellem din hotfix og master branches.

En hotfix kan checkes ud på et pre-prod/staging miljø, som more or less er en afspejling af produktion, og blive testet inden en endelig merging til master.

Release branch

En release branch brancher ud fra HEAD af develop branchen, som bliver tagget med
et versionsnummer.

git flow release start <versions-nummer>
  git flow release finish <versions-nummer>
      

En release branch er sidste skridt inden ændringerne når produktionsmiljøet, og er den branch der checkes ud på et demo/staging/pre-prod miljø, som kunden kan teste inden releasebranchen afsluttes og er klar til at blive checket ud på produktions serveren.

Hvis kunden har nogle sidste fejlrettelser på falderebet inden det lægges i produktion, så kan det blive rettet i denne branch. Det kunne ligeledes være et versionsnummer der skal opdateres i en make fil, en CHANGELOG der skal opdateres eller lignende.
Når det hele er rettet og alt er klar til lancering af ny version af projektet, så afslutter du branchen, og publiserer denne. Hvorved develop og master bliver opdateret, og nyt tag bliver oprettet.

Afvigelser fra original git-flow

I og med vi benytter os af pull requests, så afviger vi der fra git-flow fordi vi faktisk aldrig afslutter en branch, da dette er håndteret af GitHub at få merged ind.

Så kommandoerne git flow [feature|hotfix|release] finish <name> bliver på normalvis aldrig eksekveret. Og det er derfor din egen opgave at rydde op i dit lokale projekt, da alle branches stadig vil være tilgængelige.

Med git branch får du vist alle lokale branches

$> git branch
     develop
     feature/FDBOUT-366
   * feature/searchengine_update
     feature/v20
     master
      

Og du kan slette en branch du ikke har checket ud (her vist med *)

git branch -d <branch-name>

  $> git branch -d feature/FDBOUT-366
  Deleted branch feature/FDBOUT-366 (was 42b2ebc).  
      

Versionsnummering

Release og hotfixes bliver altid tagget med et , og vi bruger retningslinierne fra Semantic Versioning. For lige at opsummere lidt, så er et versionsnummer af formatet X.Y.Z.

Patch version x.y.Z benyttes til hotfixes/fejlrettelser
Minor version x.Y.z benyttes når ny funktionalitet tilføjes projektet.
Major version X.y.z benyttes oftest hvis projektet refactoreres, dvs ny kodebase, eller nyt design, dvs. store visuelle eller programatiske ændringer.

På nye projekter bør man arbejde på versionsnumre 0.y.z, og når projektet er klar til release/lancering, så tagges versionen med 1.0.

Så versionsnumre vil kunne se således ud.

Men aldrig

Github Pull Requests

En Pull request giver mulighed for at få godkendt din kode inden den merges ind i den ønskede branch (dette angives når man opretter pull requesten).
Dette sker ved at man får en anden til at kigge ens kode igennem for fejl i forhold til standarder. Men også ved at checke koden ud på sit lokale udviklings miljø og checke at den ønskede funktionalitet der er beskrevet opnås.
Hvis dette ikke skulle være tilfældet, så kommenteres der direkte på pull request siden på GitHub. Ændringer der bliver lavet til den branch der indeholder ny kode, pushes til GitHub og pull requesten opdateres automatisk med alle ædringer til branchen.

Håndtering af pull requests sker på GitHub efter at branchen er pushet derop, og man kan oprette ny pull request. Dette gøres på normalvis direkte i browser på Github.
Det er lidt omstændigt, men der findes endnu et lille tool, Hub der kan hjælpe med dette (udover en masse andre fikse git-relaterede shortcuts).

brew install hub  
      

Med hjælp fra GitHub’s API kan Hub oprette en pull-request på baggrund af forskellen mellem den branch der er checket ud (og pushed) og eksempelvis develop-branchen.

hub pull-request -b develop
      

Resultatet af denne kommando er en url til selve pull-requesten der bliver udskrevet i din kommandolinie.