I programmatori spesso riutilizzano il codice. In effetti, è uno dei principi fondamentali di qualsiasi buon codebase—Don’t Repeat Yourself (DRY). Cosa succede se si desidera utilizzare un progetto condiviso all'interno di più altri repository? Il comando git subtree può aiutare a gestirlo.
Il problema del riutilizzo del codice
L'incorporamento di progetti all'interno di altri progetti presenta un problema; Project 1 e Project 2 sono entrambi connessi a Git, ma l'utilizzo diretto del sottoprogetto condiviso per entrambi non è una buona scelta di design. Questo è essenzialmente un fork del sottoprogetto per usarlo in due posti, e sarà impossibile mantenere una versione ufficiale del sottoprogetto.
Esistono alcune soluzioni a questo problema, ognuna con i propri svantaggi.
Innanzitutto, la soluzione più ovvia è trasformare il sottoprogetto in un pacchetto e distribuirlo su un gestore di pacchetti come NPM o NuGet. Funziona molto bene per cose che non vengono aggiornate o mantenute spesso e possono permettersi di essere distribuite ai propri consumatori in numeri di versione discreti. Tuttavia, se modifichi questo codice regolarmente, dover integrare, pubblicare e estrarre nuove versioni del progetto da una fonte di terze parti semplicemente non funziona così come avere il codice direttamente accessibile. Introduce anche complicazioni per lo sviluppo locale.
L'altra soluzione è utilizzare un monorepo, un repository gigante per tutto il tuo codice. Non è così folle come potresti pensare e funziona bene se tutto il tuo codice è nello stesso dominio; Google utilizza un monorepo per tutto il loro codice e Microsoft ne utilizza uno per tutti gli assembly .NET che mantengono. Questo risolve il problema, perché se modifichi il codice nel sottoprogetto, verrà aggiornato ogni volta che lo ricostruirai. In Visual Studio, questo può essere fatto facilmente con i riferimenti del progetto.
Pubblicità
Tuttavia, ci sono molti casi in cui si desidera il meglio di entrambi i mondi, mantenendolo a livello centrale come pacchetto, ma consentendo anche l'incorporamento diretto e la modifica in più progetti. Per questo, Git Subtree fornisce una soluzione.
Il concetto di base è piuttosto semplice: puoi avere repository Git più piccoli, con i loro
Di solito, Git è abbastanza intelligente da gestire il push e l'unione automaticamente, a seconda delle modifiche provenienti da quale sottoalbero. Tuttavia, è buona norma non mischiare i commit tra il codice del sottoalbero e il codice del progetto principale, poiché ci sono casi in cui puoi imbatterti in un'unione più complicata che richiede l'utilizzo degli strumenti Git sottostanti che git subtree wraps.
Impostazione del sottoalbero Git
Se hai appena impostato un progetto vuoto e stai per impostare sottoalberi, dovrai fare un commit iniziale—anche se è vuoto—altrimenti Git genererà un errore su una TESTA ambigua. Puoi fare un commit vuoto con il seguente comando:
git commit –allow-empty -n -m “Commit iniziale”.
Desideri aggiungere il telecomando per il sottoprogetto e assegnargli un nome. Utilizzerai questo nome per fare riferimento ad esso:
git remote add -f NomeSottoalbero https://github.com/user/project.git
Quindi, puoi aggiungere il sottoalbero, al prefisso specificato. Usa il comando –squash in modo che l'intera cronologia del sottoprogetto non venga archiviata nel progetto principale.
git subtree add –prefix .Path/To/SubTree NomeSottoalbero master –squash
Uso di Git Subtree
Quando devi eseguire il pull, Git aggiornerà automaticamente solo il progetto principale, quindi dovrai recuperare il telecomando e quindi utilizzare un sottoalbero specifico comando pull. È un po' lungo, in quanto è necessario passare il prefisso, ma il lavoro viene svolto:
git fetch NomeSottoalbero master git sottoalbero pull –prefix .Percorso/A/SottoAlbero NomeSottoalbero NomeSottoalbero master –squash Advertisement
Tieni presente che puoi recuperare i commit dal telecomando, ma inserirli nel sottoalbero o inviarli al telecomando richiede l'utilizzo specifico di git subtree.
Quando arriva il momento di contribuire a monte, è necessario utilizzare git subtree push:
git subtree push –prefix=.Path/To/SubTree SubTreeName master