Differenze tra sottomodulo git e sottostruttura

300

Quali sono le differenze concettuali tra l'utilizzo di sottomodulo git e sottostruttura?

Quali sono gli scenari tipici per ciascuno?

git git-submodules git-subtree

— Nathan H
fonte

3

Questo non può rispondere a tutte le vostre domande, ma è interessante la lettura sul tema: blogs.atlassian.com/2013/05/...

— Chop

Domanda simile è stackoverflow.com/questions/571232/...

— Michael Freidgeim

"Alternative a Git moduli?": Stackoverflow.com/questions/6500524/...

— brillout

177

il sottomodulo si adatta meglio allo sviluppo basato su componenti , in cui il progetto principale dipende da una versione fissa di un altro componente (repository). Conservi
solo riferimenti nel repository principale ( gitlink , voci speciali nell'indice )

Cosa succede se desidero che i collegamenti puntino sempre all'HEAD del repository esterno?

È possibile creare un sottomodulo per seguire l'HEAD di un ramo di un repository remoto sottomodulo, con:

o git submodule add -b <branch> <repository> [<path>]. (per specificare un ramo da seguire)
o git submodule update --remoteche aggiornerà il contenuto del sottomodulo all'ultima HEAD <repository>/<branch>, per impostazione predefinita origin/master. Il tuo progetto principale seguirà comunque gli hash dell'HEAD del sottomodulo anche se --remoteviene utilizzato.

subtree è più simile a uno sviluppo basato su sistema , in cui tutto il tuo repository contiene tutto in una volta e puoi modificare qualsiasi parte.
Vedi un esempio in questa risposta .

— VonC
fonte

la tua risposta sembra andare contro la risposta votata qui: stackoverflow.com/questions/10443627/…

— Nathan H

@NathanH this (la possibilità di tracciare HEAD) è stata aggiunta un anno dopo (marzo 2013, git 1.8.2: github.com/git/git/blob/… )

— VonC

Vedo che il comportamento di followhip del sottomodulo è menzionato anche nella tua altra risposta . In tal caso, penso che intendi dire che puntare sempre all'HEAD di un sottomodulo si ottiene utilizzando entrambi add -be, --remotesuccessivamente, i comandi di aggiornamento, come nella documentazione di aggiornamento del sottomodulo . In tal caso, è -bdavvero ancora necessario per seguire HEAD del master?

— matanster

@matt the -bviene utilizzato per generare i metadati .gitmodule giusti per il sottomodulo (è equivalente a a git config -f .gitmodules submodule.<path>.branch <branch>).

— VonC,

Quindi ha poco a che fare con l'abilitazione --remote: --remotefunziona anche se -bnon è stato utilizzato add. In entrambi i casi l'aggiornamento causerà un commit nel repository principale che alloggia il sottomodulo, quindi i collegamenti non "puntano sempre all'HEAD" in modo molto automatico ... o non l'ho ricevuto, o quella affermazione meglio essere rimosso dalla risposta originale (?)

— matanster

351

sottomodulo è link;

sottostruttura è copia

— Feng
fonte

121

La differenza concettuale è:

Con i sottomoduli git in genere si desidera separare un repository di grandi dimensioni in uno più piccolo. Il modo di fare riferimento a un sottomodulo è in stile maven - stai facendo riferimento a un singolo commit dall'altro repository (sottomodulo). Se è necessaria una modifica all'interno del sottomodulo, è necessario effettuare un commit / push all'interno del sottomodulo, quindi fare riferimento al nuovo commit nel repository principale e quindi eseguire il commit / push del riferimento modificato del repository principale. In questo modo devi avere accesso a entrambi i repository per la build completa.

Con git subtree integri un altro repository nel tuo, inclusa la sua storia. Quindi, dopo averlo integrato, la dimensione del tuo repository è probabilmente più grande (quindi questa non è una strategia per mantenere più piccoli i repository). Dopo l'integrazione, non vi è alcuna connessione con l'altro repository e non è necessario accedervi a meno che non si desideri ottenere un aggiornamento. Quindi questa strategia è più per il riutilizzo del codice e della cronologia - personalmente non la uso.

— Niklas P
fonte

Ma con git subtreete puoi anche spingere - se lo desideri - giusto?

— Ixx

@lxx Se conosci l'URL del repository ...

— Franklin Yu,

@FranklinYu Perché non dovrebbe saperlo? non riesci a ottenere queste informazioni dai metadati git locali?

— adi518,

@ adi518 Sì, se sei tu quello che ha creato la sottostruttura. Tuttavia, se hai spinto il tuo repository su GitHub e altri lo hanno clonato, non credo che conosca automaticamente l'URL della sottostruttura.

— Franklin Yu,

@NiklasP - puoi approfondire "fai riferimento al nuovo commit nel repository principale"? Questo è l'unico passo che non sono chiaro su come eseguire e quindi anche il "riferimento modificato" non è qualcosa che capisco.

— Robert Oschler,

21

il sottomodulo che
spinge un repository principale su un telecomando non invia i file del sottomodulo

sotto-albero che
spinge un repository principale verso remoto spinge i file del sotto-albero

— Maciek Rek
fonte

3

"spingendo un repository principale su remoto spinge i file del sotto-albero" No, non lo fa.

— J Bramble,

@JBramble Probabilmente dovrei menzionare che è stato fatto con l'app SourceTree, ad esempio:

git -c diff.mnemonicprefix=false -c core.quotepath=false -c credential.helper=sourcetree push -v --tags production refs/heads/master:refs/heads/master

— Maciek Rek,