Smart branching med SourceTree och Git-flow

Viktigt!

graphics-warning-sign-924001

SourceTree visualiserar inte en nyskapad Branch förrän en Commit har skett parallellt till Branch som utgör parent!

Graferna kommer emellertid splittas när child Branch Mergas i parent Branch (återintegreras i föräldrabranchen).

Inledning

För några år sedan rekomenderade en artikelförfattare att anamma det som kom att kallas git-flow. Idén är att standardisera branching och merging vid featureutveckling, vid hantering av snabbfixar eller releaser samt för att komma åt de fördelar som finns inbyggt i den branch-baserade utvecklingsmodellen som Git vilar på. Det finns både för och nackdelar med flexibiliteten, men det kan bli mycket komplext om man inte strukturerar. Genom att anta ett standardiserat arbetssätt får man flera fördelar:

  • Hålla repot välstädat.
  • Arbetsprocedurer blir tydligare.
  • Förflyttning mellan projekt/brancher sker på ett förväntat och standardiserat sätt.
  • Möjliggöra för nya utvecklare att sätta sig in i projekt snabbare.

Begreppssummering

I likhet med rekommenderad mappstruktur för Subversion finns för git-flow en standardiserad branch-struktur:

  • Development branch (vanligtvis kallad ”develop”)
    Detta är branch där huvudutveckling sker. Samtliga ändringar som planeras inför nästa release placeras här, antingen genom direkta commits eller genom att integrera (merga) in andra brancher (feature-brancher).
  • Production branch (vanligtvis kallad ”master”)
    Denna branch representerar den senaste officiella kodbasen och uppdateras endast genom att merga in andra brancher.
  • Feature branches (vanligtvis med prefixet ”feature/”)
    När man arbetar med mera komplicerade applikationsuppdateringar skapar man en feature-branch och jobbar mot den. När man är klar mergar man in den aktuella feature-branchen i development-branchen.
  • Release branches (vanligtvis med prefixet ”release/”)
    När man ska ge ut en ny release skapar man en release-branch med ursprung i development-branchen. Det är tillåtet att comitta till den medan man arbetar med releasen. När den är färdig gör man merge mot både development-branchen och master-branchen (production-branch). Detta indikerar att releasen är klar.
  • Hotfix branches (vanligtvis med prefixet ”hotfix/”)
    Om man behöver göra en snabbfix till den senast gjorda releasen utan att lägga till nya och ickeverifierade features skapar man en hotfix-branch med utgångspunkt i den senast gjorda comitten till master. Så snart ändringarna är gjorda mergar man in hotfix-branchen i master-branchen igen (för att uppdatera senaste releasen), samt till development-branchen (för att säkerställa att det man ändrat även hamnar i ytterligare nästkommande relase också)!

SourceTree hjälper till med sättet att arbeta medelst git-flow som beskrivs nedanstående.

[TOP]

Sätt igång med git-flow i SourceTree

Det finns en mycket praktisk knapp att klicka på i SourceTree: Git Flow.

gitFlowButton

Baserat på i vilket skede i utvecklingsfasen som man för tillfället befinner sig hjälper den till på olika vis. Om man antar att man satt upp en git-flow-struktur på repot, samt om man befinner sig i development-branchen, kommer ett tryck på knappen som standard att föreslå ny feature. Om man istället befinner sig i feature-branchen kommer ett tryck innebära ett förslag om att avsluta och merga tillbaka till develop-branchen och så vidare.

Om det inte redan är gjort är ett förslag alltså att initialisera git-flow-strukturen för repot! SourceTree > Git Flow

[TOP]

Skapa en feature…

Givetvis kan man utan vidare comitta okomplicerade ändringar till development-branchen, men så snart det handlar om mera sofistikerade dito bör en ny feature-branch påbörjas. Just ”Start Feature” kommer att vara standardalternativet när man klickar på Git Flow och om man befinner sig i development-branchen.

För exemplets skull tänker vi oss en fortsättning av projektet FooBar från föregående bloggpost. Vi har fått i uppgift att utveckla en C#-applikation som visar en mycket enkel och okomplicerad digital klocka (inga finesser).

Eftersom vi redan har SourceTree igång, befinner oss i develop-branchen (fetstilsmarkerad) samt har initialiserat git-flow i projektet så erbjuds vi möjligheten att skapa en ny feature-branch.

Klicka på Git Flow!

Det vi kan notera från ovanstående figur är ”Preview”-fönstret som visar vad som kommer att hända när vi trycker på Ok. I vårt fall kommer en ny feature-branch (som vi givit namnet digital-clock), feature/digital-clock, skapas och det det är alltså till denna vi ska comitta våra features. Lite beroende på vilken policy som man har inom utvecklingsteamet så är det sannolikt ingen dum idé att pusha till Github (remote repo).

Det är innebär inget bekymmer om man vill växla mellan olika brancher, vare sig det är en annan feature-branch eller till något annat – det är bara att använda standardförfarandet i SourceTree för att göra det (dubbelklicka på en branch i sidomenyn eller dubbelklicka på en logpost). Värt att notera är att den ”fysiska” mappen på den lokala datorn med projektinnehåll uppdateras när man ändrar till någon annan commit! Detta är en stor skillnad mot hur TortoiseSVN hanterar motsvarande situation i Subversion!

[TOP]

Avsluta en feature…

Okej, vi har alltså lagt till Winform-projektet ”digital-clock” (projektet har för tydlighetens skull tilldelats samma namn som featurebranchen ) i FooBar, commitat och gjort push i SourceTree. Det är dags att avsluta!

När featuren är klar så används Git Flow > Finish Feature (återigen, detta kommer att vara ett av standardalternativen bland förslagen i verktygsfältet om man för tillfället befinner sig  i en feature-branch och klickar på Git Flow).

Det är standard att radera brancher som avslutas men likväl möjligt att behålla dem (avmarkera isåfall kryssrutan ”Delete branch” om det är det önskade alternativet).

[TOP]

Skapa en release

När det börjar bli dags att göra release skapar vi en särskild branch för ändamålet. Sannolikt sammanfaller det hela dessutom med att vi tillfälligtvis sätter stopp för nya features.

Det är inte svårt att skapa en release-branch, vår Git Flow-knapp hjälper oss igen! Om vi tänker oss att vi befinner oss i en development-branch, sekvensen Git Flow > [Choose Next Flow Action] Start New Release, når vi det här fönstret:

Återigen visar Preview oss att en ny branch kommer att skapas. Förra gången var det en feature-branch, nu en release-dito. I de flesta av fallen kommer vi att utgå att utgå från senast gjorda commit till development-branchen när vi vill skapa en release, men likväl är det helt okej att basera den på vilken commit som helst. Det viktigaste är att vi isolerar releasen så att den inte påverkas elementärt av annan utveckling under tiden.

Det vi gör i en release-branch är förberedelser såsom att exempelvis uppdatera versionsnummer i källkodsfilerna, ändringsloggar eller göra andra småjusteringar av liknande typ. När detta är klart är det dags att släppa releasen på så sätt som beskrivs nedan.

[TOP]

Avsluta och släppa en release

När vi då gjord våra nödvändiga uppdateringar och comittat dem till vårt repo kan vi avsluta processen. På samma sätt som när vi skapade vår release-branch hjälper Git Flow-knappen oss med nästa steg (givet att vi fortfarande utgår från vår release-branch): Git Flow > [Choose Next Flow Action] Finish Release. Dialogen som möter oss ber oss bekräfta namnet på releasen, vi får också möjlighet att sätta en etikett på (tagga) releasen med en notis samt möjligheten att välja ta bort branchen när vi avslutat.

Det senare är, återigen, mycket lämpligt att tillämpa för att undvika att det blir stökigt i repot.

Som man kan se i förhandsgranskningen (Preview) kommer release-branchen alltså att integreras i produktions-branchen (”master” eller ”develop” alltså) för att indikera att en uppdatering har skett i den utgivna versionen. Förutom detta kommer även en integrering att ske till development-branchen så att det säkerställs att den senare hålls uppdaterad.

[TOP]

En hotfix?

Men tänk då om vi snabbt måste korrigera en bug i den senaste releasen? Inte vill vi skapa en ny release eftersom ett sådant förfarande skulle inhämta även de senast gjorda ändringarna ur development-branchen. Av det skälet är det lämpligare att skapa en hotfix!

Git Flow > [Choose Next Flow Action] Start New Hotfix > Gör ändringar i koden > Commit > Push

En hotfix (snabbfix) har alltid ursprung i den senaste produktionskoden (master- eller development-branchen alltså). Förutom det så innebär hotfixar samma sak som release-branch och vidare så är det så att förfarandet är detsamma som när vi avslutar en release-branch. Ändringarna integreras i production- och development-branchen. Dessutom skapas en etikett i production-branchen för snabbfixreleasen.

Summa summarum

Git-flow är ett bra arbetssätt vid handhavande med branching i Git. SourceTree hjälper med ett enkelt och tydligt användarinterface för att anamma det.

[tillbaka till SourceTree-exempel]

Källa:

Smart branching with SourceTree and Git-flow
http://blog.sourcetreeapp.com/2012/08/01/smart-branching-with-sourcetree-and-git-flow/

Annonser