Non puoi davvero farlo. Questo non è come in OOP, dove puoi ereditare una classe e solo sovrascrivere alcune cose.
Un repository git rappresenta la cronologia del tuo progetto. Quando forzi / cloni un repository, stai costruendo su quella storia. Nota, git tratta gli archivi remoti come un ramo.
x---x---x templates
\
x---x---x project
Non puoi davvero lavorare ulteriormente sul repository dei template e poi fare un ritocco come se il tuo progetto avesse sempre incluso quel lavoro ulteriore. Bene, puoi fare unire, ma se il progetto ha cambiato uno qualsiasi dei file modello, avrai molti conflitti di fusione:
x---x---x---x-------x templates
\ \
x---x---x---merge project
Git ti consente anche di eseguire un ricontrollo della cronologia del progetto, che chiama ribasamento . Ma questo non impedisce conflitti di fusione. Devi effettivamente ancora risolvere tutti quei conflitti. Ri-basare opere riproducendo tutti i tuoi commit su una cronologia diversa, in modo da ottenere diversi commit come risultato (come mostrato da un identificatore SHA diverso). Il rebasso può anche diventare difficile se si uniscono le commit.
x---x---x---x---x templates
\ \
\ x'---x'---x' project (rebased)
\
x---x---x project (original)
Nota che, per quanto riguarda Git, la cronologia del progetto rebased è completamente scollegata dalla cronologia originale.
Il modo solo per evitare problemi: non modificare i file modello . Ma questo sconfigge lo scopo del repository template.
Non si può ragionevolmente utilizzare un repository di modelli che si clona semplicemente / fork. Non è possibile apportare modifiche al repository dei modelli in modo che siano facilmente disponibili in tutti i progetti creati da quel modello. Non appena viene avviato un progetto, puoi anche staccarlo dalla cronologia del repository del template. Se devi includere miglioramenti del modello in un progetto, il modo più semplice per farlo è probabilmente manualmente .
Potrebbe aiutare i sottomoduli git?
In pratica, a volte è preferibile includere il contenuto di un repository in un altro repository. Puoi usare git-submodules per montare un repository come directory all'interno di un altro repository. Questo ti permette di usare git come un semplice gestore di pacchetti.
superproject/
.git/
.gitmodules
module/ (module repository checked out at commit @123abc)
...
...
Ma qualsiasi modifica all'interno di quel sottomodulo è come modificare una versione clonata del repository del sottomodulo - perché è esattamente quello che è. Le modifiche non sono contenute nel superprogetto esterno. I sottomoduli di Git possono anche essere notoriamente difficili da utilizzare e richiedono un'attenzione speciale per i flussi di lavoro e i processi di compilazione. Ad esempio, i sottomoduli non vengono clonati quando cloni un superproject, a meno che tu non sia git clone --recurse-submodules .
In alcuni casi, i sottomoduli potrebbero essere una soluzione valida ai tuoi problemi - in particolare, se contengono letteralmente file modello che vengono compilati quando il tuo progetto è costruito / implementato / eseguito. Un sottomodulo potrebbe anche essere usato per fornire i file di configurazione di default.
Questo non funzionerà ancora se il modello è un modello per la struttura del progetto, o se il modello contiene file di piastre che tu modifichi manualmente.
Suggerimento personale
Dimentica git in questo scenario. Usa git per il controllo della versione, nient'altro.
Se riscontri uno standard ripetuto nei progetti, crea strumenti e librerie per eliminarlo. Richiede il minor numero possibile di file da modificare manualmente e lascia che i tuoi strumenti facciano il più possibile durante il tempo di costruzione.