Il mio progetto usa più di 100 sottomoduli git, il cui sottomodulo alternativo può gestire un sacco di repository con garbo

Question

Ho studiato sottostrutture git e altre alternative ai sottomoduli git. Il mio progetto ha oltre 100 sottomoduli ed è molto maneggevole gestirli tutti.

Qualcuno può consigliare un flusso di lavoro che funzioni davvero bene con un numero elevato di repository che devono essere mantenuti sincronizzati.

Answer 1

Se il progetto ha più di 100 sottodocumenti git di componenti e dipendenze, la loro gestione sarà ingombrante indipendentemente dall'approccio utilizzato :-) Suggerisco di cercare modi per creare script e automatizzare il maggior numero di parti possibile. Fidati di me, la novità di giocare e incatenare i comandi di git si consuma molto rapidamente per la maggior parte delle persone, specialmente quando le scadenze si avvicinano. C'è già un'ottima risposta here sul confronto tra i diversi approcci per gestire i sottoprogetti git.

Per quanto riguarda il flusso di lavoro, innanzitutto separerò i repository che sono sotto il vostro controllo da quelli che non sono i repository di terze parti.

Per repository di terze parti che non cambiano spesso (tramite fusioni o PR a monte), è ancora possibile utilizzare i sottomoduli. In genere, questi sottomoduli verranno puntati sull'HEAD di alcuni tag stabili. Sincronizzarli è solo questione di esecuzione (o scripting) git submodule update --recursive --remote. Se queste dipendenze di terze parti possono essere specificate in strumenti di gestione dei pacchetti come bundler (for ruby projects), ciò aiuterà a semplificare la gestione dei sottoprogetti.

Per i repository personali e che cambiano spesso, sia gitslave o git-subtree sono due alternative, a seconda delle preferenze del team.

multiplex gitslave git operazioni in più rami. IOW, quando diramazioni, unione, commit, push, pull ecc., Ogni comando verrà eseguito a turno sul progetto padre e su tutti gli slave. Ciò impone al team di lavorare in modo top-down, partendo dal super-progetto fino agli schiavi.

gitsubtree utilizza la funzionalità subtree merge di Git per ottenere un effetto simile a quello dei sottomoduli, memorizzando effettivamente i file nel repository principale e unendo le modifiche direttamente a quel repository. Il risultato finale è un archivio canonico con la possibilità di includere la cronologia di tutti i sottoprogetti. In un certo senso, questo consente ai membri del team di concentrarsi maggiormente sui sottoalberi di cui sono responsabili, ma richiederà un lavoro supplementare per unire di nuovo all'albero genitore.

Come sviluppatore, la mia preferenza è lavorare a livello di sottoprogetti inferiori (per fare il mio "red, green, refactor" cycle) e toccare i progetti padre solo quando necessario. Tuttavia, indipendentemente dal fatto che si scelga un flusso di lavoro dall'alto verso il basso o dal basso, provare a identificare i passaggi ripetitivi soggetti a errori nella propria strategia di unione & e copiarli il più possibile.