Come convertire più repository Git per il codice correlato in rami / tag appropriati

3

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.

    
posta errantlinguist 29.03.2018 - 17:15
fonte

2 risposte

4

Poiché questi singoli repository sono stati copiati dall'originale, è possibile ristabilire la relazione tra le copie e l'originale. Consulta questa altra risposta per ulteriori dettagli.

Utilizza git remote add in ciascuna delle copie per fare riferimento all'originale. È quindi possibile verificare che i nomi delle filiali in ogni copia non siano in conflitto tra le copie e iniziare a risincronizzare le copie con l'originale. Git si prenderà cura di ristabilire la struttura ad albero nel repository originale, perché questo è ciò che fa git.

    
risposta data 29.03.2018 - 17:43
fonte
0

I team scientifici possono essere difficili da gestire. Di solito hanno poco o nessun background nell'ingegneria del software e il software è pronto per la produzione quando funziona.

Sembra che tu abbia la soluzione tecnica di @BobDalgleish - che mi sembra giusta. Ma hai un problema di modello mentale più grande che ha spinto le persone che lavorano nel software verso una soluzione che è inappropriata. Copiare l'intero repo, cambiarlo leggermente e rilasciarlo per Project x / y / z mostra una mancanza di previsione.

Forse una soluzione più appropriata è quella di creare un piano per regolare il modo in cui le persone lavorano - cambiarle dal fare un obiettivo a breve termine nel modo più rapido possibile, a un obiettivo a più lungo termine di aumentare il set di funzionalità disponibile saranno progetti che non richiedono alcun codice personalizzato. L'idea di cosa sia una vera release potrebbe essere loro estranea e dovrai prendere l'iniziativa.

Cerca di non dire loro che hanno funzionato male e li correggerai: i progetti devono aver avuto successo a un certo livello. Cerca di farli acquisire nell'idea di un'immagine più grande e poi aiutarli a girare l'angolo facendo molto lavoro e strutturando e aiutandoli a realizzare progetti più piccoli all'interno del framework.

    
risposta data 29.03.2018 - 19:55
fonte

Leggi altre domande sui tag