Sottomoduli: concetto fondamentale, flussi di lavoro e suggerimenti

Vorrei iniziare spiegando brevemente un concetto fondamentale sui sottomoduli che ne semplificherà l'utilizzo.

I sottomoduli sono monitorati dal commit esatto specificato nel progetto principale, non da un branch, da un riferimento o da qualsiasi altro riferimento simbolico.

Non vengono mai aggiornati automaticamente quando viene aggiornato il repository specificato dal sottomodulo, ma solo quando viene aggiornato il progetto principale stesso. Come espresso molto chiaramente nel capitolo Pro Git menzionato in precedenza:

O in altre parole:

Tenendo a mente questo concetto fondamentale e riflettendoci sopra, puoi comprendere che i sottomoduli (submodule) supportano bene alcuni flussi di lavoro e altri in modo meno ottimale. Esistono almeno tre scenari in cui i sottomoduli rappresentano una scelta corretta:

• Quando un componente o un sottoprogetto cambia troppo velocemente o le modifiche imminenti interromperanno l'API, puoi bloccare il codice su un commit specifico per ragioni di sicurezza.

• Quando c'è un componente che non viene aggiornato molto spesso e che desideri monitorare come dipendenza del fornitore. Io procedo così per i plugin vim, ad esempio.

• Quando deleghi una porzione del progetto a una terza parte e desideri integrare il suo lavoro in un momento o in un rilascio specifico. Ripeto: questo procedimento funziona quando gli aggiornamenti non sono troppo frequenti.

Ringrazio finch per le ottime spiegazioni degli scenari.

L'infrastruttura dei sottomoduli è molto solida e consente un'utile separazione e integrazione delle basi di codice. Esistono tuttavia operazioni semplici le cui procedure non sono intuitive o che non sono efficacemente supportate dall'interfaccia utente da riga di comando.

Se nel tuo progetto usi i sottomoduli git, avrai già incontrato queste operazioni oppure lo farai a breve. Quando ciò accadrà, dovrai andare a cercare la soluzione. Più e più volte. Ti faccio risparmiare tempo: aggiungi questa pagina a Instapaper, Evernote o ai più tradizionali segnalibri (:D:D) per essere a posto per un po'.

Quindi, ecco alcune procedure che ti torneranno utili:

Questo è un flusso di lavoro molto comune: inizi a utilizzare il progetto di qualcun altro come sottomodulo, ma dopo un po' vuoi personalizzarlo e modificarlo in autonomia, quindi vuoi eseguire un fork del progetto e sostituire il sottomodulo con il tuo fork. Come si fa?

I sottomoduli sono archiviati in .gitmodules:

Puoi semplicemente modificare l'URL con un editor di testo e quindi eseguire quanto segue:

In questo modo aggiorni .git/config, che contiene una copia di questa lista di sottomoduli (potresti anche modificare semplicemente la sezione [submodule] pertinente di .git/config manualmente).

Riferimenti su Stack Overflow

È un'esigenza abbastanza comune, ma prevede una procedura leggermente complicata. Per rimuovere un sottomodulo devi:

1. Eliminare la riga pertinente dal file .gitmodules.

2. Eliminare la sezione pertinente da .git/config.

3. Eseguire git rm --cached path_to_submodule (senza slash finale).

4. Eseguire il commit ed eliminare i file dei moduli secondari ora non monitorati.

Riferimenti su Stack Overflow

Oppure, in altre parole: come faccio ad annullare la struttura del sottomodulo da un sottomodulo git? Se tutto ciò che vuoi è inserire il codice del sottomodulo nel repository principale, devi rimuovere il sottomodulo e aggiungere nuovamente i file nel repository principale:

1. Elimina il riferimento al modulo secondario dall'indice, ma conserva i file:

2. Elimina il file .gitmodules, o, se hai più di un modulo secondario, modifica questo file rimuovendo il modulo secondario dalla lista:

3. Rimuovi la cartella dei metadati .git (assicurati di averne creato un backup):

4. Aggiungi il modulo secondario submodule all'indice del repository principale:

NOTA: la procedura descritta sopra è distruttiva per la cronologia del sottomodulo. Nei casi in cui desideri conservare una cronologia coerente dei sottomoduli, devi eseguire un "merge" più complesso. Per maggiori dettagli consulta questo riferimento molto completo su Stack Overflow.

A volte i moduli secondari (submodules) potrebbero diventare dirty da soli. Ad esempio, se usi git submodules git per tenere traccia dei plugin vim, questi potrebbero generare o modificare file locali come gli helptags. Purtroppo, git status inizierà a infastidirti relativamente a queste modifiche, anche se non ti interessano affatto e non hai intenzione di sottoporle a commit.

La soluzione è molto semplice. Apri il file .gitmodules alla radice del repository e, per ogni sottomodulo che vuoi ignorare, aggiungi ignore = dirty come in questo esempio:

Grazie a Nils per l'ottima spiegazione.

Come ci ricorda il tutorial sui sottomoduli Git disponibile su kernel.org, ci sono alcune cose importanti da ricordare quando si interagisce con i repository remoti.

La prima è pubblicare sempre la modifica al sottomodulo prima di pubblicare la modifica al superprogetto che vi fa riferimento. Si tratta di un passaggio fondamentale in quanto potrebbe impedire ad altri di clonare il repository.

La seconda è ricordarsi sempre di eseguire il commit di tutte le modifiche prima di eseguire il comando git submodule update, poiché le eventuali modifiche verranno sovrascritte!

Grazie a queste note, dovresti essere in grado di affrontare molti comuni flussi di lavoro ricorrenti che emergono quando si utilizzano i sottomoduli. In un prossimo post scriverò sulle alternative a git submodule.

Seguimi alla pagina @durdn e segui anche il fantastico team di @Bitbucket per altre informazioni su DVCS.