[Linux-Biella] petizione riguardo il sito bilug.it

[Daniele Segato]

Il giorno mer, 29/12/2010 alle 22.39 +0100, Federico Villa (Villinux) ha
scritto:
> Il 21 dicembre 2010 14:47, Paolo Ciarrocchi
> > Viene inoltre fatto un uso un po' particolare di HG, non c'e' infatti
> > un commit per funzionalita' ma ci sono grossi commit con descrizione
> 
> Si, lo ammetto, dobbiamo ancora imparare bene ad usare HG ed a fare i commit.

beh ma non ce nulla di male a non conoscere :)

su git c'è un comando:

git rebase --interactive <commit>

che ti permette di riscrivere la storia dei tuoi commit _LOCALI_ (molto
importante non modificare commit di cui si è già fatto il push)

io quando lavoro faccio moltissimi commit, con commentini che spiegano
quel che ho fatto.
anche se non compila, è sbagliato, ci sono TODO o codice che uso per
testare all'interno..
è nei miei commit

poi quando ho finito faccio un rebase interattivo per sistemare la
storia di lavoro: tolgo i commit che mi son segnato come "di test",
sistemo l'ordine, riscrivo i commenti di commit per spiegare cos'ho
fatto e perché (il perché se non è ovvio)

cerco di dividere i commit per in modo che siano: il più piccoli
possibili ma autoconsistenti.

quindi effettuo il push.

questo fa si che il mio lavoro sia chiaro a chi guarda i commit e in
futuro si possa risalire al perché è stata scritta ogni riga di codice
anche a chi non lo ha mai visto.

è più facile identificare i bug, comprendere il flusso, effettuare
revert e portarsi dietro modifiche al codice in branch che non le hanno.

Inoltre, per ogni nuova funzionalità creo un branch e lavoro su quello,
poi faccio merge e push quando ho finito

se devo modificare quella funzionalità la modifico su quel branch e
ri-effettuo un merge.

se c'è un bug identifico il commit che lo ha generato, creo un branch a
partire da quel commit, lo sistemo e ne faccio il merge nei branch in
cui mi occorre.

Così facendo ogni branch rappresenta una funzionalità o una fix: il che
rende più facile importare la funzionalità in giro o fare dei backport.


Quando c'è un bug, se sei in grado di scrivere un piccolo script bash
che decide se il bug è presente o meno un:

git bisect run <script-di-test>

ti trova il commit che introduce il problema, e se i commit sono piccoli
e atomici è piuttosto facile, in genere, identificare la causa del
problema.

Un'altra cosa che trovo utile è definire un template dei commenti di
commit, io uso questo:

* 1 riga corta che descrive "cosa fa" il commit
* una riga vuota
* la descrizione dettagliata della modifica effettuata
* (opzionale) [Ticket: #....] se si usano eventuali sistemi di
bugtracking per mantenere il collegamento con i ticket aperti sul bug
tracking
* (opzionale) tre righette ---
* (opzionale) dopo le righette scrivere il perché si sono prese certe
decisioni o esprimere eventuali incertezze o mancanze sul codice

trovo che forzarsi a seguire questo meccanismo porti ad ottenere un
flusso di lavoro pulito e a una maggior consapevolezza delle modifiche
apportate al codice: forzandosi a suddividere i commit in piccole parti
spiegandoli ci si rende spesso conto di errori o mancanze, o più
semplicemente che quel commit poteva esser fatto meglio, forzandosi a
spiegare il perché di una decisione tecnica ci si obbliga a valutarla e
così via...

Si impiega un po' più di tempo che però viene ampiamente recuperato
quando si deve risolvere un problema o si deve introdurre qualcuno al
progetto o, ancora, si deve riprendere in mano un codice scritto 2 anni
prima... (ecc...)

Suppongo ci siano strumenti simili anche su Mercurial ma non lo conosco
quindi lascio agli altri tradurti questi comandi nell'idioma hg e spero
di esserti stato utile.