On 03/30/2017 08:37 AM, Gollum1 wrote: > In che modo dovrebbe essere gestito un repository di sviluppo? Partiamo da un presupposto: queste sono mie considerazioni basate da quanto ho visto in giro e da come mi regolo io nel gestire un repository. Analizzando il repository BitBucket di Genropy:
Commit: Per come la vedo io, un commit dovrebbe essere riferito ad un solo evento, ovvero mai riferirsi a due modifiche differenti. Per capirci, un commit che incorpora un fix e che incorpora una modifica di sviluppo non deve esistere. Inoltre, per me i commit dovrebbero essere il più granulari possibile, anche riferiti al cambio di una sola linea di codice (git da questo punto di vista aiuta parecchio, essendo decentralizzato). Questo perché non solo è più facile capire l'evoluzione del codice, ma è anche più facile eseguire operazioni di rebase o di cherry-pickying. Da quello che ho visto (un paio di commit, in realtà), in Genropy vengono incorporati i commit, cosa che come ho detto per me è Male™ Branch[1]: Partiamo da un presupposto, esistono due tipi di branch: quelli di sviluppo di funzionalità (i feature branch) e quelli di mantenimento/hotfix del prodotto. La differenza è semplice: i primi sono branch che nascono per una deviazione dello sviluppo e muoiono, mediante merge o mediante cancellazione, quando questa deviazione finisce. Inoltre, molti li usano per definire dei workflow differenti da quello standard[2][3]. Da quello che mi è sembrato di capire, in Genropy viene usato un workflow basato su di un branch di sviluppo/feature/hotfix, ma mi sembra che ci siano anche dei branch che non c'entrano nulla con tutto il resto. Ora, le motivazioni possono essere due: o i branch in più sono di funzionalità che sono rimasti per storico o per mancata cancellazione, o sono deviazioni dallo sviluppo principale per customizzazioni specifiche. Nel primo caso, vedo un peccato "veniale", ovvero semplicemente non è stata fatta pulizia del repository, mentre nel secondo vedo un peccato più grave perché ogni customizzazione non riportata nel ramo principale significa non solo che ogni fix dev'essere riportato su tutti i branch, ma che c'è una gestione malsana del progetto, quindi spero che il progetto non si trovi in quest'ultimo caso. Tag: Qua vedo non è che ci sia molto da dire, per come l'ho intesa io i tag in Genropy sono usati alla stregua di branch. Comunemente i tag in qualsiasi sistema di controllo di revisione vengono usati per rilasciare la nuova versione del software, tanto che basta vedere il repository di un qualsiasi altro software per notare questa convenzione e che molti software di supporto li gestiscono in tal senso (e.g. Github rilascia automaticamente una versione del tuo software non appena compare il tag). Va da sè che è qua che per me, quello che fino a sopra era sopportabile (mi si perdoni il termine), diventa inaccettabile. Non vedo un senso alla gestione dei tag, e quindi non è chiaro quanto e come si sta evolvendo il software. Per quanto riguarda il repository Github, invece, posto che sono d'accordo con le osservazioni dell'issue aperta, quello che vedo è non solo la mancanza di tag (che aiuterebbe non poco), ma uno scarso utilizzo del mezzo. Per intenderci, per quanto anche io sia un estimatore di BitBucket, Github permette di avere più visibilità rispetto a qualsiasi altro sistema di gestione dei repository, pertanto considererei veramente una migrazione del repository di sviluppo. In definitiva, allo stato attuale quello che farei è questo: - Rivedrei tutti i tag utilizzando un sistema di versioning esplicativo[4] rispetto all'attuale. - Eliminerei tutti i branch morti, più per pulizia che altro. - Ristrutturerei il repository utilizzando come tracce di esempio [2] o [3], visto che ben si adattano al workflow che si sta utilizzando in questo momento Enrico [1] A tal proposito, consiglio sempre di seguire questo: http://learngitbranching.js.org/ <http://learngitbranching.js.org/> [2] http://nvie.com/posts/a-successful-git-branching-model/ [3] https://about.gitlab.com/2014/09/29/gitlab-flow/ [4] http://semver.org/ _______________________________________________ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python