Grande layout del progetto: aggiunta di nuove funzionalità su più sottoprogetti

Voglio sapere come gestire un grande progetto con molti componenti con il sistema di gestione del controllo versione.

Nel mio progetto attuale ci sono 4 parti principali.

1. ragnatela
2. server
3. Console di amministrazione
4. Piattaforma.

La parte web e server utilizza 2 librerie che ho scritto. In totale ci sono 5 repository git e 1 repository mercuriale. Lo script di compilazione del progetto si trova nel repository Platform. Automatizza l'intero processo di costruzione.

Il problema è quando aggiungo una nuova funzionalità che interessa più componenti, devo creare un ramo per ciascuno dei repository interessati. Implementa la funzione. Uniscilo indietro. Il mio istinto è "qualcosa non va".

Quindi dovrei creare un singolo repository e mettere lì tutti i componenti? Penso che la ramificazione sarà più facile in quel caso. O faccio semplicemente quello che sto facendo in questo momento. In tal caso, come posso risolvere questo problema di creazione di diramazioni su ciascun repository?

Nella situazione che descrivi, non stai ottenendo alcun vantaggio dall'avere più repository, ma hai un costo: non puoi tornare a una versione precedente di un repository e avere la certezza che il tuo sistema continuerà a funzionare. Questo perché il codice è strettamente accoppiato tra i repository. Poiché la fiducia nella capacità di rollback è uno dei principali vantaggi del controllo del codice sorgente, questa non è la situazione in cui si desidera essere.

La soluzione consiste nel definire la struttura del repository in base all'accoppiamento del codice al suo interno: se il componente A del progetto condivide solo interfacce stabili con il componente B del progetto, possono essere collocati in repository separati. Altrimenti, dovrebbero essere collocati nello stesso repository. Un layout di repository più granulare rifletterà un'architettura di sistema meglio fattorizzata.

Se ciascuno dei tuoi repository è costituito da progetti o librerie indipendenti, direi che non c'è nulla di intrinsecamente sbagliato nella necessità di creare rami di funzionalità su ciascun repository quando si aggiungono nuove funzionalità che attraversano i progetti. Essendo stand-alone, ognuno può essere autonomamente sottoposto a versione e puoi deprecare le vecchie API.

Ma nel tuo caso particolare, sembra che i tuoi repository potrebbero non raggruppare il codice in modo efficace. Se le modifiche al codice in un repository richiedono modifiche ad altri (deprecazione a parte), l'accoppiamento è troppo stretto o i repository dovrebbero essere riorganizzati.

Se tutti i repository fanno davvero parte dello stesso progetto (non possono essere autonomi), forse dovresti avere solo 1 repository. (O forse 2: il progetto principale e uno per funzionalità generica / standardizzata.)