Scegliere tra progetti singoli o multipli in un repository git?

Ci sono tre principali svantaggi di one project per repository , come descritto sopra. Questi sono meno veri se si tratta di progetti veramente distinti, ma dai suoni che ne derivano cambiano spesso i cambiamenti in un altro, il che può davvero esagerare con questi problemi:

1. È più difficile scoprire quando sono stati introdotti errori. Strumenti come git bisect diventano molto più difficili da utilizzare quando si frattura il repository in sotto-repository. È possibile, non è così facile, ovvero caccia al tesoro in tempi di crisi è molto più difficile.
2. Il monitoraggio dell'intera cronologia di una funzione è molto più difficile. I comandi di attraversamento della cronologia come git log non generano la cronologia degli output in modo significativo con strutture di repository fratturate. Puoi ottenere un output utile con i sottomoduli o sottoalberi o altri metodi di scripting, ma non è lo stesso che digitare tig --grep=<caseID> o git log --grep=<caseID> e scansione di tutti i commit che ti interessano. La tua storia diventa più difficile da capire, il che la rende meno utile quando ne hai davvero bisogno.
3. I nuovi sviluppatori impiegano più tempo ad apprendere la struttura del controllo delle versioni prima che possano iniziare la codifica. Ogni nuovo lavoro richiede procedure di prelievo, ma la fratturazione di un repository di progetto significa che devono raccogliere la struttura VC oltre all'architettura del codice . Nella mia esperienza, questo è particolarmente difficile per gli sviluppatori nuovi di git che provengono da negozi tradizionali e centralizzati che utilizzano un unico repository.

Alla fine, è un calcolo del costo opportunità. In un precedente datore di lavoro, la nostra applicazione principale era suddivisa in 35 diversi repository secondari. In cima a loro abbiamo usato un complesso set di script per cercare la cronologia, assicurandoci che lo stato (cioè produzione e rami di sviluppo) fosse lo stesso su di loro, e distribuirli individualmente o in massa.

Era semplicemente troppo; troppo per noi almeno. Il sovraccarico di gestione ha reso le nostre funzionalità meno agili, ha reso le implementazioni molto più difficili, ha insegnato ai nuovi sviluppatori a impiegare troppo tempo e, alla fine, riuscivamo a malapena a ricordare perché abbiamo fratturato il repository in primo luogo. Un bel giorno di primavera, ho speso $ 10 per un pomeriggio di tempo di calcolo in cluster in EC2. Ho riavviato i repository con un paio di dozzine di% di chiamate digit filter-branch. Non ci siamo mai voltati indietro.

Christopher ha svolto un ottimo lavoro nell'enumerazione degli svantaggi di un modello di un progetto per singolo repository. Vorrei discutere alcuni dei motivi per cui potresti considerare un approccio a repository multipli. In molti ambienti in cui ho lavorato, un approccio multi-repository è stato una soluzione ragionevole, ma la decisione di quanti repository avere e dove fare i tagli non è sempre stata facile.

Nella mia attuale posizione, ho migrato un repository CVS di un singolo repository di Behemoth con oltre dieci anni di storia in una serie di repository git. Da quella decisione iniziale, il numero di repository è cresciuto (attraverso le azioni di altri team), al punto in cui sospetto che avremmo più di quanto sarebbe ottimale. Alcuni neoassunti hanno suggerito di unire i repository ma ho discusso contro di esso. Il progetto Wayland ha un'esperienza simile. In un discorso che ho visto di recente, avevano, a un certo punto, oltre 200 repository git, per i quali il lead si scusava. Guardando il loro sito web , vedo ora che sono a 5, il che sembra ragionevole. È importante osservare che unire e suddividere i repository è un compito gestibile, ed è giusto sperimentare (entro limiti ragionevoli).

Quindi quando potresti volere più repository?

1. Un singolo repository sarebbe troppo grande per essere efficiente.
2. I repository sono liberamente accoppiati o disaccoppiati.
3. Generalmente uno sviluppatore ha bisogno solo di uno o di un piccolo sottoinsieme di repository da sviluppare.
4. In genere vuoi sviluppare i repository in modo indipendente e devi solo sincronizzarli occasionalmente.
5. Vuoi incoraggiare più modularità.
6. Diversi team lavorano su diversi repository.

I punti 2 e 3 sono significativi solo se il punto 1 vale. Suddividendo i nostri repository, ho ridotto in modo significativo i ritardi subiti dai colleghi esterni, ridotto il consumo di dischi e migliorato il traffico di rete.

4 e 5 sono più sottili. Quando dividi i repository di un client e un server, ciò rende più costoso coordinare le modifiche tra il codice client e il codice server. Questo può essere positivo, in quanto incoraggia un'interfaccia disaccoppiata tra i due.

Anche con gli aspetti negativi dei progetti multi-repository, un sacco di lavoro rispettabile viene svolto in questo modo: vengono in mente wayland e boost. Non credo che un consenso sulle migliori pratiche si sia evoluto ancora, e sia necessario un certo giudizio. Gli strumenti per lavorare con più repository (git-subtree, git-submodule e altri) sono ancora in fase di sviluppo e sperimentazione. Il mio consiglio è di sperimentare ed essere pragmatico.

Poiché utilizziamo GitHub, in realtà abbiamo più progetti in un repository ma assicurati che quei progetti / moduli siano correttamente modularizzati (usiamo -api e -core convenzioni + Maven + controllo statico e di runtime e potrebbe persino andare a OSGi un giorno per l'avvio).

Che cosa risparmia? Bene, non dobbiamo rilasciare più richieste di pull se stiamo cambiando qualcosa di piccolo su più progetti. Problemi e Wiki sono mantenuti centralizzati ecc.

Trattiamo ancora ogni modulo / progetto come un progetto indipendente appropriato e lo costruiamo e integriamo separatamente nel nostro server CI ecc.

Per me, la principale differenza nell'utilizzo di uno o più repository sono le risposte alle seguenti domande:

• Le parti multiple sono sviluppate dallo stesso team, hanno lo stesso ciclo di rilascio, lo stesso cliente? Quindi ci sono meno motivi per dividere l'unico repository.
• Le parti multiple altamente sono dipendenti l'una dall'altra? Quindi la suddivisione del modello, del controller e dell'interfaccia utente (anche quando sono parti differenti) non è molto ragionevole, a causa dell'alta dipendenza reciproca. Ma se 2 parti hanno solo una piccola dipendenza, che è implementata da un'interfaccia stabile che viene cambiata solo ogni pochi anni, quindi sarebbe saggio dividere le 2 parti in 2 repository.

Proprio come un esempio, ho una piccola applicazione (solo client), che controlla la "qualità" di un repository Subversion. C'è l'implementazione di base, che può essere avviata dalla riga di comando, e funziona bene con Java 6. Ma ho iniziato a implementare un'interfaccia utente, che utilizza JavaFX come parte di Java 8. Quindi ho diviso il 2 e creato un secondo repository (con un secondo processo di compilazione), con un programma diverso, ...

Mi piacciono le risposte sopra (le ho votate), ma penso che non siano l'intera storia vera. Quindi volevo aggiungere gli argomenti per dividere anche i repository. Quindi la vera risposta (quando dividere) potrebbe essere da qualche parte nel mezzo ...

Potrebbe essere git-subtree (vedi Blog di Atlassian , blog medio o kernel link ) sarebbe una buona misura per quello che hai. Quindi, ciascuno dei tuoi progetti di livello superiore userebbe un insieme di elementi secondari a versioni o versioni diverse.