Layout del repository GIT per server con più progetti

Una delle cose che mi piace del modo in cui ho installato Subversion è che posso avere un singolo repository principale con più progetti. Quando voglio lavorare su un progetto posso dare un’occhiata a quel progetto. Come questo

\main \ProductA \ProductB \Shared 

poi

 svn checkout http://.../main/ProductA 

Come nuovo utente di git voglio esplorare un po ‘di buone pratiche sul campo prima di impegnarmi in un stream di lavoro specifico. Da quanto ho letto finora, git memorizza tutto in un’unica cartella .git nella radice dell’albero del progetto. Quindi potrei fare una delle due cose.

  1. Impostare un progetto separato per ciascun prodotto.
  2. Imposta un singolo progetto massiccio e archivia i prodotti in sottocartelle.

Esistono dipendenze tra i prodotti, quindi l’unico progetto massiccio sembra appropriato. Useremo un server in cui tutti gli sviluppatori possono condividere il loro codice. Ho già lavorato su SSH e HTTP e su quella parte che amo. Tuttavia, i repository in SVN sono già di molte dimensioni GB, quindi trascinare l’intero repository su ciascuna macchina sembra una ctriggers idea, soprattutto perché ci viene addebitato un eccesso di larghezza di banda della rete.

Immagino che i repository del progetto del kernel Linux siano ugualmente grandi, quindi ci deve essere un modo corretto di gestirlo con Git, ma non l’ho ancora capito.

Esistono linee guida o best practice per lavorare con repository multi-progetto di grandi dimensioni?

La linea guida è semplice, per quanto riguarda i limiti Git :

  • un repository per progetto
  • un progetto principale con sottomoduli .

L’idea non è quella di archiviare tutto in un gigantesco repository git, ma creare un piccolo repository come progetto principale, che farà riferimento ai giusti commit di altri repository, ognuno dei quali rappresenta un progetto o un componente comune a sé stante.


L’ OP Paul Alexander commenta :

Sembra simile al supporto “esterno” fornito da subversion.
L’abbiamo provato e abbiamo trovato estremamente ingombrante aggiornare costantemente i riferimenti di versione negli esterni poiché i progetti vengono sviluppati contemporaneamente alle dipendenze reciproche. C’è un’altra opzione ??

@Paul: sì, invece di aggiornare la versione dal progetto principale, puoi:

  • sviluppare i sottoprogetti direttamente dal progetto principale (come spiegato in “La vera natura dei sottomoduli “),
  • o si fa riferimento in un sub-repo a origin verso lo stesso sub-repo sviluppato altrove: da lì è sufficiente tirare da quel sub-repo le modifiche apportate altrove.

In entrambi i casi, non devi dimenticare di impegnare il progetto principale, per registrare la nuova configurazione. Nessuna proprietà “esterna” da aggiornare qui. L’intero processo è molto più naturale.

Onestamente, questo suona come un vero dolore e tutto ciò che richiede agli sviluppatori di fare qualcosa manualmente ogni volta sarà solo una normale fonte di bug e manutenzione.
Suppongo che cercherò di automatizzare questo con alcuni script nel super progetto.

Ho risposto:

Onestamente, potresti avere ragione … fino all’ultima versione di Git 1.7.1 .
git diff e git status entrambi appresi per tenere conto degli stati dei sottomoduli anche se eseguiti dal progetto principale.
Semplicemente non puoi perdere la modifica del sottomodulo.

Detto ciò:

  • i sottomoduli sono diversi dagli esterni di SVN: vedi ” Perché i sottomoduli git sono incompatibili con gli svn esterni? ”
  • gestire i sottomoduli può essere complicato: vedi ” Come funziona esattamente il sottomodulo git? “.

GitSlave ti consente di gestire diversi repository indipendenti come uno. Ogni repository può essere manipolato da normali comandi git, mentre gitslave consente di eseguire un comando su tutti i repository.

 super-repo +- module-a-repo +- module-b-repo gits clone url-super-repo gits commit -a -m "msg" 

Il Repo-per-project ha vantaggi con la componentizzazione e le build semplificate con strumenti come Maven. Repo-per-project aggiunge protezione limitando l’ambito di ciò che sta cambiando lo sviluppatore, in termini di commit errati di garbage.