Come usare git

La bibbia: Feature branch workflow

I nomi dei branch

• Sviluppo: feature-something
• Hotfix master: fix-something
• Hotfix produzione: hotfix-something

Creare una feature

1. Allinearsi alla versione aggiornata di master
   • git checkout master
   • git fetch origin
   • git reset --hard orgin/master ATTENZIONE, questo comando sovrascrive la vostra working copy con master
2. Creare un branch
   • git checkout -b [miobranch]
3. Lavorare come pazzi e, ogni tanto, fare un rebase con master
   • git commit #ovvero accertarsi di non avere nulla di utile presente solo nella working copy
   • git checkout master
   • git pull
   • git checkout [miobranch]
   • git rebase --preserve-merge master
   • Risolvere eventuale conflitti
   • git push --force-with-lease (solo se già pushato, quando sapete di dover rebasare conviene non pushare)
   • Ripendere a lavorare

Mettere il codice in prova su devel

1. Aprire una pull-request verso master
   • Mettere il branch su devel da pannello
   • Fare e far fare test
   • In caso di errori, SI CORREGGONO NEL BRANCH GIA' IN PULL REQUEST
     Il push su quel ramo causerà l'aggiornamento automatico di devel (4002)

Mettere il codice in prova su master

1. Richiedere il merge su master, con una richiesta di review (o su whatsapp, ovviamente)
2. Test finali di integrazione, in caso di errori si apre un branch di hotfix, ribranchandolo da master, NON dal branch feature (che viene cancellato una volta mergiato)
3. Anche master (4001) viene aggiornato automaticamente ad ogni push
4. Quando tutto va bene...

Mettere il codice in produzione su release

1. Da github fare una release a partire dal ramo MASTER (dall'apposita tab di github). Usiamo il semantic version
2. IMPORTANTE Titolo e descrizione della release finiscono direttamente in motd e news, quindi è importante che siano esaustivi ma NON tecnici. Ai giocatori interessa sapere che "Non crasha piu' dando il comando register senza parametri" non "Corretto dangling pointer"
3. Se possibile, per le release notes usate questo stile:
   

   TITOLO DELLA RELEASE (non importa il numero, viene aggiunto automaticamente)
   - Fix: per i bug fix
   - Feature: per le novità
   - Tech: per i miglioramenti del codice solo tecnici. 
     Di solito si tralasciano ma se una release contiene solo questi 
     almeno non mettiamo una descrizione vuota
   

4. Quando finalizzate la release, un hook crea un nuovo branch col nome rnumerodirelease. Se avete rilasciato la 9.3.7, il nuovo branch sara' r9.3.7
5. Per il deploy, sempre da pannello anche se per ora ha accesso solo Alar :)

Hotfix release

1. Per modifiche sotto le 10 righe, si modifica direttamente il branch di produzione (rqualcosa), altrimenti si brancha da quello e poi si apre la pull request di nuovo verso di lui
2. IMPORTANTE Titolo e descrizione della pull request finiranno (a breve) direttamente in motd e news, quindi è importante che siano esaustivi ma NON tecnici. Ai giocatori interessa sapere che "Non crasha piu' dando il comando register senza parametri" non "Corretto dangling pointer"
3. Per il deploy, sempre da pannello anche se per ora ha accesso solo Alar :)

Comandi utili

Cancellare un tag locale: git tag --delete nometag
Cancellare un tag remoto: git push --delete origin nometag
Cancellare un branch locale: git branch --delete nomebranch
Cancellare un tag remoto: git push --delete origin nomebranch
Rimuovere dalla propria working copy i rami rimossi dal server: git remote prune origin