RFC: Branch naming guidelines

[havremunken]

Flytter over litt fra nå lukket task.

• master - denne dilter etter og representerer ca. hvor vi er, ikke klart å lage en god stratergi i hodet ennå.
• prod-live - dette representerer tilstanden til extension som er live og ikke beta. Trigger build og deploy til Chrome web store.
• prod-beta - dette er beta extension for de som føler for det. Trigger build og deploy. Eller blir dette feil måte å gjøre det på? Hadde kanskje vært bedre med en dropdown inne i extension setttings hvor man velger hvilken man skal ha, men hvordan gjør vi det isåfall? Usikker. Krever mer forskning.
• feature-something - denne ser jeg for meg i all hovedsak lever lokalt på våre respektive maskiner, men vi kan selvfølgelig også dele dem på github om vi må samarbeide om enkelte ting.
• fix-issuenr - jobber på en bugfix.

Enig med det du skrev i den andre issue'n - for å holde dem adskilt, skal vi kalle dem bugfix-xxxx og feature-xxxx med issuenr.? Da er det vel relativt enkelt å holde en noenlunde frisk mental modell gående.

Så rebases bare live/deploy-branchene mot disse bugfix/feature-branchene etterhvert som de er klare.

Vi bør vel kanskje likevel ha en form for prosess så vi ikke krasjer stygt hvis vi jobber på separate features samtidig eller noe.

[larsjaas]

Lokale brancher bør navnsettes "local-*" slik at de kan slettes av hvem som helst, om de skulle pushes til GitHub ved en feiltagelse.

[larsjaas]

Foreslår "prod-stable" fremfor "prod-live" egentlig.

[larsjaas]

Merge-teknikk er jo en relatert greie. Føler kanskje en branch bør i hvertfall rebases før det skjer en merge mot master eller andre branches, og vi kan også vurdere squashing, selv om jeg er fan av å se hvert inkrement av feature-utviklingen også i master-brancher.

[havremunken]

prod-stable høres bra ut.

Jeg liker selv rebasing og "rene" git-historikker, men vi får se hva som er praktisk gjennomførbart. Om det betyr at vi sier fra til hverandre når vi integrerer endringer eller hvordan vi gjør det må vi finne ut av.

Er det en tanke å si at vi har følgende "offentlige" branches (dette er bare en braindump foreløpig):

stable beta prod-stable prod-beta development

Livssyklusen til en ny feature blir da noe sånt.

1. Lag en ny branch av development, local-xxxx etter issuenummer. Utvikle lokalt til den er klar til å deles.

2. Lag en offentlig feature branch under development. Integreres med annet pågående arbeid så det ikke er merge-konflikter e.l., men for moduler skal jo de utvikles i isolasjon så langt som mulig så det bør være mulig å få til.

3. Få den over i beta-branchen når den er klar for å testes i neste beta release.

4. Inn i prod-beta når beta milestone nås og ny versjon shippes.

5. Når kvaliteten ser ut til å være ok kan den få leve i stable.

6. Så blir den med i prod-stable når neste milestone kommer.

Er dette sinnsykt overkill? Kan vi holde det på et høyt nivå uten så altfor mye byråkrati?

[havremunken]

Selvfølgelig mulig å lage milestone-branches som man kan hekte seg på også.

[havremunken]

Jeg ser for meg at dette lett kan bli litt enklere.

Jeg vil fortsette med local-xx her hos meg. Så lenge de er local er de "by nature" under utvikling og ikke klare til å sees av noen.

Når koden så kan begynne å tåle dagslys, kan jeg velge å pushe greina ut, da som feature-xx eller fix-xx - avhengig av om jeg jobber på ny funksjonalitet eller fikse noe som ikke virker.

Så kommer cluet - vi har tre branches som vi henger disse feature-xx/fix-xx på:

• alpha: Alle branches som henger på denne er under utvikling og bør kun håndteres av oss to, og ev. fremtidige kode-sjonglører. Uferdig kode som ikke må kjøres av ukyndige.

• beta: Når en branch "forfremmes" hit er den av en sånn kvalitet at betatesterne kan utsettes for den. Den er forventet å virke men trenger testing.

• stable: Her havner ting som er klar for verden.

Men her kommer min manglende erfaring på multiplayer git inn - jeg kan jo stort sett rebase meg oppover i en rett linje på ting jeg jobber med, fordi jeg er alene. De endringene jeg har gjort i en feature-xx branch, la oss si fire stk - hvis jeg hekter den på alpha, vi to jobber litt med den, og den får to nye commits. Seks totalt. Kan så alpha rebases på denne for å innlemme den i "current alpha", og kan vi så rebase feature-xx mot beta og holde denne greina separat selv om den har blitt en del av alpha? Eller tenker jeg feil her?

Workflow-tips mottas med takk fra @larsjaas :)

[larsjaas]

Jeg er ikke innkjørt i noe ultimat system for dette selv. Har noen litt ukonvensjonelle ideer som kanskje hadde vært kult å prøve ut.

Men først - alpha, beta, stable - ingen av disse vil nødvendigvis være noen rett strek med commits, og der det er forgreninger så må branchnavn være forskjellig for hver gren. Du har kanskje parallelt beta-versjoner for 1.3 og 2.0, tilsvarende for alpha, og kanskje v1.3.1 slippes etter at 2.0.3 er sluppet. Det kunne i alle fall vært sånn med et stort bibliotek som trenger å release bugfikser til gamle versjoner, men for en chrome extension er det neppe noe reelt problem. De blir sikkert rette streker alle branchene, og det er uaktuelt som crome-extension bruker å holde tilbake versjoner men oppdatere med bugfixer.

Men skulle man egentlig kjørt branch alpha-1.0.x, alpha-1.1.x, beta-1.0.x osv og alltid branchet ut nytt branch-navn når man jobber mot en ny versjon? Hva skal i såfall CI deploye fra? Skal man ha en tag ('alpha-current'?) som man flytter rundt?

Når det kommer til stable (stable-1.0.x osv) så tenker jeg den kunne vært ultra-clean, med én release, én commit, én tag. På en måte en komplett squash mellom hver release. Og med et sånt revisjonshistorikk-tre så trenger den ikke være koblet til andre brancher i det hele tatt, annet enn at man vil for hver commit finne lik tilstand i beta-branche'ene etter siste release-candidate for den gitte versjonen. Så man kunne lagt en "blank branch" for dette hvor første commit var første release. Jeg er dog usikker på hvor bra det vil fungere å gjøre git diff mellom en sånn branch og en urelatert arbeidsbranch. Skal ikke forundre meg om det fungerer helt fint dog. Og å flytte kode fra beta til en commit for stable er bare et par 'git reset'-kommandoer unna.

Angående installasjon og test, så blir det vel slik at det man klassifiserer som alpha vil alltid måtte installeres fra source i en browser i developer mode. Beta bør deployes og installeres fra chrome web/extension store. Stable selvsagt det samme.

Hva slags formål skal alpha ha i forhold til master? Er master en plass man kan commit'e kladder, ting som ikke fungerer, og kanskje ikke kompilerer, mens alpha i utgangspunktet alltid skal kompilere og henge sammen?

Det går an å bygge pene forgrenede trær i alpha via å gjøre git cherry-pick for riktig feature-branch i alpha-treet fra de relevante commitene i master. Om du lager en alpha-feature-merge dog, så vet jeg ikke helt hvordan du skal kunne holde feature-branchene adskilt om de videreutvikles videre. Det er forsåvidt enkelt nok å bygge videre på de individuelle feature-branchene, men et nytt merge-punkt blir ganske rotete i branch-treet i alle fall, og rebasing og squashing vil skape en skog med søppel i git-repoet og kunne føre til uønskede overraskelser (brancher man har jobbet på er plutselig flyttet) når folk gjør en git pull. Nei, tror jeg må sove på den biten, til over cupfinalen i alle fall...