Newsgroup: it.lavoro.informatica
Titolo: git flow

conoscete/usate questo modello di sviluppo?
 
http://nvie.com/posts/a-successful-git-branching-model/
 
 
pareri? giudizi?

Ciao rootkit,

In uno dei team per cui lavoro lo utilizziamo già da qualche mese.
Personalmente mi trovo *benissimo*. Le prime due settimane può sembrare 
un po' cervellotico, ma ora come ora non tornerei indietro (questo però 
non esclude che non si possa andare avanti :-)).
 
Ciao,
Giulio
 
-- 
 
 
 


Io lo uso, davvero ottimo, e costringe tutti ad usare git come dio comanda.
 
  ngw


Molto interessante, non conoscevo
Effettivamente tenersi ordinati col branching di git a volte è una lotta
Può essere un buon metodo
 
Al momento io sono un po' più selvaggio: ho un master "quasi" sempre 
affidabile, ma ho dei rami "feature" che a volte sono vittime della 
fretta ...
 
Thx
 
-- 
I fatti mi cosano

 fretta ...
 
è la prima cosa che noi si voleva evitare.
mi piace l'idea dei due "never ending branch", master e development. finora
per noi l'unico riferimento era il master, l'head del master era lo stato dello
sviluppo e i tag i rilasci in produzione. però è un casino immane quando si
deve fare il rilascio perché peschi dal calderone dove tutti buttano e 
sicuramente nell'head ci sono feature che non devono essere rilasciate, 
costringendoti una volta sì e l'altra pure a dei voli pindarici.


Sto provando giusto adesso
Ho creato un ramo dev a partire dal branch "piccolaFeatureLimitata" che 
ormai comprende un refactoring profondo dell'interfaccia, fix a vari 
bug, varia nuove feature ....
 
Come č facile diventare disordinati quando si lavora da soli
 
-- 
I cosi mi fattano

 Come è facile diventare disordinati quando si lavora da soli
 
Tocca quotare. Io ho lavorato da solo per moltissimo tempo e ora, che mi tocca avere un ruolo da coordinatore oltre che da sviluppatore, sto facendo una fatica bestia.
 
Per questo ho dato un occhio allo schema linkato da rk, e devo dire che lo trovo logico anche se applicato a svn (noi usiamo svn internamente). E ho iniziato a leggere il libro che è citato, per carpirne i principi.
 
-- 
Ciao!
Luca

 lo trovo logico anche se applicato a svn (noi usiamo svn internamente).
 
in realtà penso che con svn sia inapplicabile. in primo luogo perché non 
è distribuito quindi tutti i "giochi" di branch vanno fatti sul remoto, 
in secondo luogo perché svn non ha strumenti per merge efficienti (anzi 
si può dire non ne ha proprio). il processo è tutto nel ribaltare branch/
commit da un branch all'altro, farlo con svn lo vedo proprio come un 
incubo.
 
 

 finora per noi l'unico riferimento era il master,
 
Significa che non hai mai dato una occhiata al repository di git...
 
Te lo consiglio, anche perchè è il mio riferimento per la qualità dei 
messaggi di commit; non è però il mio riferimento per la qualità e 
organizzazione del codice, il mio riferimento in questo caso è Nginx.
 
 
Ciao  Manlio


È un modello assolutamente ragionevole, chiaro che se i "team" sono tre 
persone e uno committa il 90% del codice non è detto che l'overhead, pur 
ridotto, valga la candela.


onestamente non penso sia così. 
anche dove lavoro da solo io sono ormai abituato a ad aprire un branch 
per ogni modifica che inizio, almeno da quando utilizzo git, perché 
oggettivamente su git è una pratica che costa niente ed ha indubbi 
vantaggi primo fra tutti non sporcare il ramo principale con commit 
inconsistenti.
 

 inconsistenti.
 
Ok su questo, ma se hai un branch che va avanti per lungo tempo e sul
ramo principale vengono fatti aggiornamenti, poi riportare le modifiche
dal ramo principala al branch senza fare il merge è un casino.
In teoria ci dovrebbe essere il rebase per questo, ma a me quando l'ho
usato ha fatto solo un gran casino per cui lo evito.
 
 

 dal ramo principala al branch senza fare il merge è un casino.
 
e che cambia lavorando direttamente sul ramo principale? forse intendi 
dire che in questo modo tieni aggiornato il tuo master e quindi eviti il 
"big bang" finale, ma si ottiene lo stesso risultato anche nell'altro 
modo. niente vieta che tu, periodicamente, ricevi il master aggiornato e 
ribalti gli aggiornamenti sul tuo branch, il costo usando git è 
esattamente lo stesso.


Intendevo dire che ribaltare gli aggiornamenti che ci sono sul master
nel branch è un casino se non vuoi fare il merge. Se il branch va avanti
per lungo tempo, vorrei periodicamente poter aggiornare i file del
branch con le versioni nel ramo master. Poi potrebbe benissimo essere
che sono io imbranato con git.
Attualmente uso i branch solo quando so che le modifiche che sto facendo
potrebbero pestare i piedi ad altro (mi capita un giorno di lavorare su
una cosa, poi doverla sospendere per altro e riprenderla n giorni dopo).

 nel branch è un casino se non vuoi fare il merge. 
 
si ma quello che ti sto dicendo io è che *comunque* se ci sono conflitti 
il merge prima o poi lo devi fare. anche se lavori sul tuo master locale 
prima o poi dovrai sincronizzare col master di origin per mandare le tue 
modifiche. 

 una cosa, poi doverla sospendere per altro e riprenderla n giorni dopo).
 
i merge sono talmente inexpensive che si committa di frequente proprio 
per evitare la situazione che descrivi
 
tra l'altro l'articolo postato da rootkit spiega appunto i vantaggi di 
questo approccio, che a mio giudizio sono evidenti anche lavorando da 
soli
 
-- 
A million bright ambassadors of morning
 
 

 questo approccio, che a mio giudizio sono evidenti anche lavorando da soli
 
Probabilmente mi sono perso qualcosa nell'articolo a sto punto. Rileggo.

 Probabilmente mi sono perso qualcosa nell'articolo a sto punto. Rileggo.
 
nell'articolo viene appunto spiegato (tra le altre cose) come sia utile 
avere un branch di sviluppo in movimento, lasciando in master solamente 
le release e i bugfix importanti
 
nel lavoro di gruppo, capita spesso che il team dedicato alle nuove 
feature faccia regolarmente il merge da develop, in modo che eventuali 
patch e correzioni siano importati localmente e si possa lavorare su 
codice pulito


 le release e i bugfix importanti
 
a questo scopo suggerisco anche di dare un occhiata a strumenti grafici 
come smartgit/hg che supportano il flusso di gitflow e sono di ottimo 
ausilio per il lavoro di tutti i giorni. io anche se preferisco di norma 
la commandline lo trovo molto utile.