Concettualmente, un sottomodulo Git non è un sotto-repository che è incluso nel repository principale. Invece, un sottomodulo è un puntatore a una specifica revisione di un altro repository. Oltre a questo puntatore, tutti i repos sono completamente indipendenti.
Il repository padre memorizza solo questo puntatore di revisione. Pertanto, quando esegui una revisione diversa di un sottomodulo (ad esempio mediante il commit delle modifiche), devi anche impegnare il nuovo valore del puntatore di revisione nel repository padre.
Questo significa che usare i sottomoduli è abbastanza complicato per rappresentare diverse parti di un progetto, e funziona molto meglio quando si sta vendendo un progetto diverso nell'albero dei sorgenti. Cioè visualizzare i sottomoduli come un tipo molto basilare di sistema di gestione delle dipendenze. Dovresti impegnare un nuovo puntatore di revisione del sottomodulo sul repository principale se vuoi includere una nuova versione di tale dipendenza.
Quando si progetta un'architettura di repository Git, questo rende i sottomoduli poco interessanti per le parti in rapida evoluzione del progetto, e meglio per le librerie abbastanza stabili con un ciclo di rilascio più lento. Se diverse parti cambiano insieme, tenerle insieme in un unico repository coesivo è probabilmente meglio.