Git submodule vs Git clone

18

Sto lavorando a un progetto open source su GitHub.

Ha una sottodirectory / fornitore in cui ha una copia di diverse librerie esterne. Il manutentore originale del progetto ha aggiornato questa directory di tanto in tanto con una copia più recente della libreria esterna.

Uno sviluppatore mi invia una richiesta pull con l'idea di sostituire questa copia con git submodule .

E sto considerando se è una buona idea o no.

Pro del sottomodulo Git:

I sottomoduli sono stati progettati specificamente per scenari simili
Rimuove la possibilità di commit accidentale per il fornitore che verrà sovrascritto durante il prossimo aggiornamento

Contro del sottomodulo Git:

Sembra che git submodules spinga la complessità dal manutentore a una persona che clonerà / tirerà il progetto (ulteriori passaggi richiesti dopo la clonazione per iniziare a lavorare con il progetto: "git submodule init", "git submodule update"

Qual è la tua opinione su questo?

Un'altra cosa. Questo problema è una libreria di dimensioni ragionevolmente ridotte con dipendenze esterne molto limitate. Penso che qualsiasi strumento di costruzione sarebbe eccessivo per ora.

git github

— Victor Ronin
fonte

4

In alternativa possono farlo git clone --recursivee quindi non devono eseguire i comandi del sottomodulo. Nessun altro aveva menzionato questo bocconcino; la maggior parte delle persone che conosco che hanno sottomoduli pubblicizzano questo nel README.

— Levi Morrison,

9

Un'alternativa a un sottomodulo è usare git subtree. Ciò offre i vantaggi, git submodulema senza spingere la complessità all'utente finale. Il repository di terze parti viene unito nella struttura principale del progetto, ma i metadati vengono archiviati in modo tale da poter:

estrarre il repository di terze parti in seguito, se sono state apportate modifiche interessanti
unisci nuovi aggiornamenti dal repository di terze parti (nota unione , non sovrascrivere)

Per gli utenti Git che non sono abbastanza sofisticati da comprendere i sottomoduli, l'approccio dei sottotree rende non più difficile ottenere un clone del progetto di qualsiasi altro clone. Un breve blurb dalla documentazione:

Le sottostrutture consentono di includere i sottoprogetti in una sottodirectory del progetto principale, opzionalmente includendo l'intera cronologia del sottoprogetto.

Ad esempio, è possibile includere il codice sorgente di una libreria come sottodirectory dell'applicazione.

I sottotitoli non devono essere confusi con i sottomoduli, che sono pensati per lo stesso compito. A differenza dei sottomoduli, i sottotitoli non necessitano di costruzioni speciali (come file .gitmodule o gitlink) presenti nel repository e non costringono gli utenti finali del repository a fare qualcosa di speciale o a capire come funzionano i sottotitoli. Una sottostruttura è solo una sottodirectory che può essere impegnata, ramificata e unita con il progetto nel modo desiderato.

Avevo creato un progetto al lavoro usando i sottomoduli, e i problemi con l'aggiornamento dei sottomoduli nei cloni di tutti erano troppo lavoro. Di recente sono passato a usare sottotitoli ovunque e quei problemi sono scomparsi.

Nota che git-subtree fa parte della git/contribdirectory e deve essere installato separatamente.

— Greg Hewgill
fonte

4

Uno svantaggio dell'utilizzo dei sottomoduli è che i tarball o gli archivi zip su Github (e molti altri servizi) non includono le fonti dei sottomoduli. Cioè, gli archivi non sono autonomi. Questo è un problema se il repository è piccolo e in realtà non ha uno script di compilazione, come un sito HTML statico a seconda di una libreria JavaScript.

— Lekensteyn
fonte

3

Questo è il posto ideale per usare i sottomoduli. Riducono le dimensioni e la complessità del repository e semplificano l'aggiornamento delle librerie esterne a una nuova versione.

Non sono difficili da capire come usare e sono abbastanza comunemente usati in questa situazione, quindi prendi nota nel README del progetto che fai uso di sottomoduli e cosa fare e che le persone dovrebbero essere in grado di capire fuori. La prima volta che ho incontrato un repository con un sottomodulo l'ho messo in funzione in 10-15 minuti e non ho mai avuto problemi a capire cosa fare da allora.

— Jonathan Patt
fonte

1

Come aggiunta a questo, se la tua applicazione non riesce a inizializzare, potresti voler mettere in atto un controllo per verificare che il sottomodulo sia stato inizializzato - e fornire un messaggio di errore amichevole se non lo è.

— Jonathan Rich

1

Vedi anche la risposta di Lekensteyn sugli archivi zip privi di file di sottomodulo. Ciò significa che i sottomoduli non sono forse l'approccio migliore se si sta fornendo codice pubblicamente, ma vanno bene per il codice privato che è garantito per essere clonato. Altrimenti, preferisci i sottotitoli.

— Ingegnere,

3

L'uso dei sottomoduli impedisce di apportare modifiche locali al codice e crea una dipendenza dal repository esterno. Se sei sicuro di non voler mai personalizzare una libreria o apportare correzioni di bug locali e puoi essere sicuro che il server esterno sarà sempre disponibile quando vuoi clonare una nuova copia, è la strada da percorrere.

In breve: vuoi semplicemente usare le librerie o le consideri parte della tua base di codice? Se non sono il "tuo" codice, perché hanno il controllo della versione e non solo qualcosa che devi aver installato?

— Sean McSomething
fonte

6

I sottomoduli non ti impediscono di apportare modifiche locali. Al contrario, ti consentono di tenere traccia di tali modifiche e utilizzare versioni diverse (le tue modifiche o le versioni della libreria) della libreria in diversi progetti.

— Steve Fallows