È buona norma suddividere il grande repository in più piccoli per avere una cronologia / un problema separato ecc. o tenerlo grande? [duplicare]

Question

È buona norma suddividere il grande repository in più piccoli per avere una cronologia / un problema separato ecc. o tenerlo grande? [duplicare]

#1 da (1 voti)
#2 da (1 voti)
#3 da (0 voti)

7

Al momento stiamo eseguendo il porting del nostro enorme svn repo su git e stiamo pensando di esportare sottodirectory di repository, ognuna contenente codice sorgente di binari indipendenti, documentazione o test di robot, in progetti separati di git.

Una di queste è una libreria attualmente in fase di sviluppo e tutti i binari dipendono da questo.

Tutte queste directory / binari / documenti ecc. sono attualmente sviluppate.

Dovremmo separare tutti questi elementi in repository Git separati o aggiungere sottomoduli o tenerlo come se fosse un enorme repo?

Struttura del catalogo:

/trunk/src/
    binary1/
    binary2/
    binary3/
    binary4/
    binary5/
    library/
    TA_tests/
    docs/
    scripts/

git svn repository scm porting

posta Patryk 21.01.2015 - 17:33

fonte

3 risposte

Leggi altre domande sui tag git svn repository scm porting

Come modellare hashtag con nodejs e mongodb DDD: modello di fabbrica modello di dominio

score 1 · Answer 1

Mantenere un solo grande repository è un errore per me perché la tua tempistica di commit sarà appesantita da molti commit che non hanno nulla a che fare con il tuo progetto e sarai bloccato spesso al momento del push senza alcun motivo.

Penso che tu abbia tre scelte:

sottomoduli git : se desideri un certo grado di separazione tra la tua librairy e il tuo repository. Può essere giustificato se vuoi disaccoppiarli leggermente. Offre un modo gestito per gestire la tua dipendenza ma ti fornisce un punto di correzione per i tuoi aggiornamenti.
Avere un manager dipendente che corregge la versione che si desidera utilizzare (come fa Compositore ). Il vantaggio qui è quello di essere in grado di controllare la versione che si utilizza e di non avere brutte sorprese quando si aggiorna il repository. Ma devi ricordarti di aggiornarlo quando cambia.
git subtree : questo è il soluzione più accoppiata, se si desidera un modo trasparente per affrontare questa dipendenza. Il vantaggio qui è quello di non essere in grado di dimenticare di aggiornare la dipendenza, ma potresti correre dei guai se la tua libreria vi rompe il codice.

Dipende davvero dal tuo flusso di lavoro. Se la libreria e il repository sono strettamente accoppiati, scegli git subtree, se vuoi un controllo rigoroso della tua dipendenza, scegli un gestore dipendente come, se non scegli git submodules.

score 1 · Answer 2

Per il mio lavoro usiamo repository separati e manteniamo versioni per ogni modulo.

Pro

Non tutti i moduli sono necessari per ogni progetto, quindi siamo in grado di mantenere facilmente le dimensioni di ogni progetto
La cronologia dei commit è specifica per il modulo
È facile utilizzare versioni specifiche o rami del modulo quando necessario.

Contro

Dobbiamo usare un gestore di pacchetti per mantenere le dipendenze
Le dipendenze possono avere conflitti, ad es. un modulo requres v0.1.3 di un modulo chiamato utility e un altro modulo richiede la v2.0.2 delle utility

Altri pensieri

Se il progetto su cui ti trovi è un singolo progetto con molte parti, è meno importante mantenere le cose separate. Potrebbe essere ancora più semplice se ogni modulo fosse separato. Ma se hai molti progetti piccoli o medi che usano vari moduli, è molto utile avere repository separati.

score 0 · Answer 3

Penso che sarebbe una grande idea perché manterrà le cose belle e ordinate per gli umani che dovrebbero leggerlo. Di solito uso sottodirectory con il mio codice per renderlo più leggibile. Non usare codice leggibile dall'uomo mi dà mal di testa e mi rende molto difficile cercare le cose. La cosa migliore che puoi fare è mettere il file eseguibile principale nella directory home e interrompere tutto il resto. Buona fortuna!