Newsgroup: it.comp.os.linux.sys
Titolo: git workflow

Sono nuovamente alle prese con git per un progetto di medie dimensioni.
Ho necessità di ottenere uno sviluppo analogo a quello Debian/Ubuntu, dove Ubuntu scarica le modifiche di Debian e ci mette sopra le personalizzazioni.
 
Attualmente ho su "master" il progetto originale sul quale baserò le mie modifiche, ho creato un branch apposito di nome "miavariante", copia di "master" sul quale faccio tutti miei smanettamenti.
 
Fin qui sarebbe OK. Il problema nasce quando dovrò scaricare le variazioni fatte dall'autore originale ed adattarle alle mie modifiche. Pensavo:
 
1. scarico su master il software 'originale'
2. faccio il merge di master in 'miavariante'
3. gestisco le collisioni mediante git come di consueto.
4. nel caso l'autore originale facesse ulteriori variazioni, riparto da 1.
 
Può andare come sistema o avete procedure migliori e maggiormente testate?

 testate?
 
Direi che e` la procedura corretta, per la mia esperienza.
 
Bye.

 Direi che e` la procedura corretta, per la mia esperienza.
 
E' già qualcosa. :)
 
Supponendo ci siano da portare avanti due o più rami dello stesso software, come nel caso di clienti con pesanti customizzazioni, su master mi tengo sempre il software "originale" in modo da farne il pull (o, come nel mio caso, una brutale estrazione da file zippato di origine), poi faccio il merge su ciascuno dei miei rami di sviluppo. Che siano 2-3-4 o più cambia poco, parto da master, faccio il merge, risolvo i conflitti che le mie personalizzazioni sicuramente introdurranno e così via, per tutti gli altri.

 testate?
 
Credo che sia l'unica.
 
Se l'autore originale avesse un suo repository GIT sarebbe facilissimo.
 
 

 Se l&#39;autore originale avesse un suo repository GIT sarebbe facilissimo.
 
No, usa SVN.


Vale la pena provare ad usare git2svn o roba simile per sincronizzare 
l'archivio SVN dello sviluppatore con il tuo.
 
Se riesci a tenere le cose sincronizzate (ed una volta messo in piedi 
devi solo fraccare un bottone), allora puoi considerare come "master" 
quello dello sviluppatore e fare il merge di tutta la roba nuova nel tuo 
branch senza problemi, sfruttando le potenzialità di GIT.
 
 

 branch senza problemi, sfruttando le potenzialità di GIT.
 
Beh, ma anche senza git2svn dovrei riuscire a farlo.
Quando lo sviluppatore fa variazioni, tiro giù tutto mediante svn (o mediante tar.gz, che forse faccio prima), sovrascrivo tutto quello che trovo nel mio master, "git add . && git commit -am 'Sync sviluppatore remoto'" e poi il merge nel mio branch tramite git.
 
Tenere lo storico delle variazioni che fa lo sviluppatore non serve, posso fare un brutale e selvaggio replace di tutto quello che ho in master e poi ragionare con calma.

 master e poi ragionare con calma.
 
Per come funziona GIT, salvarsi lo storico aiuterebbe con i merge (e non 
poco).
Tra l'altro saresti sicuro di non perderti dietro niente.
 

 Tra l&#39;altro saresti sicuro di non perderti dietro niente.
 
E come è possibile? Se sovrascrivo tutto oppure cancello e ricreo, come faccio a dimenticarmi un pezzo?

 faccio a dimenticarmi un pezzo?
 
Ci vuole estremamente poco.
E dopo aver letto quello sopra non lo farai.
 
E dopo aver letto questo:
 
http://nvie.com/posts/a-successful-git-branching-model/
 
 
Sarai ancora meno convinto di farlo
 
:P
 
 

 Sarai ancora meno convinto di farlo
 
Io faccio in maniera differente:
il 'master' da me è la versione di sviluppo, sul quale tutti pastrocchiano (l'equivalente del trunk svn).
 
Se un cliente dovesse chiedere una customizzazione che difficilmente tornerà utile ad altri, si crea un branch e si lavora li, in caso contrario, tutti lavorano sul master.
 
Ad un certo punto lo sviluppo raggiunge un livello stabile. Si crea un branch chiamato v1.0.0stable che, al momento della sua creazione conterrà un clone del master. Da questo momento in poi chi lavora sul branch stable sarà decapitato.
 
Se c'è da cambiare una virgola, lo si fa sul master. Nel caso il bugfix fosse di vitale importanza, si può effettuare la stessa variazione anche sul ramo stabile e taggarne il commit.
 
Come metodo sembra funzionale, ma uso/usiamo git da troppo poco per poter valutarne eventuali lati negativi.
 
Quello che invece ho scoperto e CHE NON RIFARÒ MAI PIÙ, NEMMENO SOTTO TORTURA CINESE è scaricare un repositori (non git) esterno dentro il master per poi farne il merge dentro un mio branch. ho spaccato tutto lo spaccabile ed anche file di cui nemmeno ero a conoscenza. Porco mondo, non lo rifarò mai più.
 
la soluzione è molto più semplice e molto più oldschool, ma nelle mie circostanze ovvero dove il mio branch differisce sensibilmente dal programma originale, molto più affidabile:
 
- installo Trac (o chi per lui)
- installo SVN
- scarico il trunk di tanto in tanto (rimanendo sempre dentro SVN)
- uso la comodissima Timeline di Trac per visualizzare la variazioni tra una release e l'altra.
- copia-incolla a raffica delle variazioni dal software originale al mio branch. Se il file fosse nuovo o sensibilmente modificato, faccio l'inverso: copia il file e riapplico le mie variazioni anzichè applicare le variazioni di terzi al mio.
 
Uso questo sistema con successo anche su un altro progetto da circa 1 anno (ma senza passare da SVN in quanto quest'altro sviluppatore ha un Trac pubblicamente accessibile). e' una rottura di palle immensa quando vengono fatte molte variazioni, ma almeno so sempre cosa modifico, dove e quando.
 
Il merge fatto oggi ha portato via 1 ora. Più l'intera giornata di domani a risolvere "non so cosa" visto che non funziona più nulla. Se avessi fatto il copia-incolla non sarebbe successo nulla.
 
Ma Ubuntu come fa? C'è scritto da qualche parte?
 

 non lo rifarò mai più.
 
beh, a parte che fare un rollback è questione di 3 minuti, ma mi pare 
strano che venga fuori un casino del genere.
 

 strano che venga fuori un casino del genere.
 
Sai che sono in difficoltà? Ieri ho volutamente fatto il merge seguito da commit in modo da poter tornare indietro, ma non riesco a tornare al mio ultimo commit prima del patatrack.
 
Sto usando SmartGIT (assurdo che un software scritto da Linus, per Linux, non abbia una GUI decente per Linux, invidio TortoiseGIT su Windows ai miei colleghi)
 
Il problema (che ho avuto anche quando ho fatto il merge) è che git cerca di unire dei PNG calcolandone le differenze. Non ci riesce, e si incazza non poco.
Ora per tornare indietro mi dice che ci sono dei conflitti. Ma non vedo cosa gli possa interessare, deve fare il rollback ad un commit as-is fregandosene dei conflitti (che non ci possono essere, visto che non deve fare alcun merge ma un rollback)


Due considerazioni:
1) GIT è distribuito. Se hai fatto commit ma non merge, riprenditi le 
versioni del tuo branch aggiornate all'ultimo push dall'origin/master.
 
2) elimina i conflitti, perchè git si incazza se devi fare un rollback e 
ci sono delle modifiche. Non vuole farti perdere dati.
 
 
SmartGit non lo conosco, io vado di command line ... quindi non so 
aiutarti.
 
 

 ci sono delle modifiche. Non vuole farti perdere dati.
 
Ho risolto così:
 
- creo un branch "gandalf_ok" a partire da un dato commit.
- lo pusho in remoto (che poi il remoto sarebbe il mio server interno)
- cancello il branch originale "gandalf", sia da locale che da remoto
- creo un branch "gandalf" partendo da "gandalf_ok"
- lo pusho in remoto
- cancello da locale e da remoto "gandalf_ok"
 
Notifico gli altri sviluppati a riclonare il progetto ,altrimenti al primo push che mi fanno mi risovrascrivono il branch con le modifiche non buone.
 
non capisco però per quale motivo debba cercare di unire dei PNG