Sfondo
Recentemente sono diventato il responsabile tecnico / sviluppatore senior di un piccolo team di R & D / data science. Ho una discreta quantità di esperienza non-lead in team di sviluppo più grandi, ma non ho alcuna istruzione formale in project o team management.
Ci sono alcuni programmatori esperti nel team, ma gli altri non hanno avuto molta esperienza lavorando su progetti più grandi. Attualmente usano Git per gestire la propria base di codice anche se in modo non convenzionale: finora, le persone sono state effettivamente "ramificate" copiando l'intera base di codice per un progetto come un nuovo repository. In pratica "taggano" il repository con un nome descrittivo e quindi in gran parte non lo toccano quando "rilasciano" il codice taggato a meno che non venga scoperto un errore critico.
Ad esempio, ecco come cercare i prodotti arthur e lancelot :
small_companys_code
├── arthur (this is the "basic" bleeding edge "branch" of project "arthur")
├── arthur-Jan2015 (this is a "tag" for a stable release in Jan 2015)
├── arthur-multilang (this is a "development branch" for the new feature "multilang")
├── arthur-multilang-Mar2016 (this is a "tag" for a release in Mar 2016 with a new feature "multilang", maybe not necessarily merged into the repo "arthur")
├── arthur-fred (these are the personal changes of the former employee Fred. No one remembers exactly what changes this has)
├── lancelot (this is the "basic" bleeding edge "branch" of project "lancelot")
├── lancelot-Feb2018 (this is a "tag" for a stable release in Feb 2018)
├── lancelot-Feb2018-spanish (this is almost exactly the same as "lancelot-Feb2018" but was quickly changed to support Spanish for demonstrating)
Funziona abbastanza bene per le persone che sono rimaste abbastanza a lungo da sapere dov'è tutto. Tuttavia, per le persone nuove (me compreso), questo è probabilmente molto scoraggiante.
Obiettivo
Una delle mie responsabilità ufficiali è di "ripulire" e, in tal modo, assicurarmi innanzitutto che ci sia sempre una versione funzionante e rilasciabile di ogni progetto ( arthur e lancelot sopra). Il flusso di lavoro esatto è indeciso al momento; Il mio compito immediato è di riorganizzare il codice principalmente in modo che ci sia sempre una versione "ultima" stabile del codice che possa essere facilmente implementata ed eseguita anche se non ha necessariamente tutte le funzionalità sviluppate per altre versioni (cioè sperimentale o funzioni pianificate per il futuro):
small_companys_code
├── arthur (repo for project "arthur")
| ├── master (branch for project "arthur" including only tested features which will definitely be included in later versions of product)
| | ├── Jan2015 (release tag)
| | ├── multilang (branch for new feature)
| | | ├── Mar2016 (release tag for demo'ed version of feature "multilang")
| | ├── fred (orphaned branch to eventually be merged/removed)
├── lancelot (repo for project "lancelot")
| ├── master (branch for project "lancelot" including only tested features which will definitely be included in later versions of product)
| | ├── Feb2018 (release tag)
| | ├── spanish (branch for quickly-hacked "feature", possibly to be developed or merged but maybe just removed)
| | | ├── Feb2018 (release tag for one-off demo)
Come posso affrontare questo compito? Poiché i repository sono stati essenzialmente copiati nella maggior parte dei casi, non posso fare affidamento sulla ricerca attraverso i log di commit Git. Ovviamente posso dare un'occhiata alle date reali del mondo reale per i cambiamenti e creare un ordinamento cronologico dei diversi repository, ma non sono sicuro di come posso usare queste informazioni per creare un flusso di lavoro Git adeguato come quello mostrato sopra.