Condividere il codice tra filiali in diverse cartelle

Question

Ho un repository con due rami (master e gh-pages). La struttura delle cartelle del mio master ramo assomiglia a questo:

/dist 
    /js 
    /css 
/other-folders 

Nel mio gh-pages ramo, ho una cartella _include con alcuni file in essa contenuti. Voglio condividere il mio codice nelle /dist/css e /dist/js cartelle con il mio gh-pages ramo, in modo che la mia struttura di cartelle gh-pages simile a questa:

/_include 
    /js 
    /css 

o

/_include 
    /dist 
     /js 
     /css 

è qualcosa di simile possibile con git? Non posso usare

git subtree push --prefix dist origin gh-pages 

perché questo basta copiare il /dist in un'altra cartella /dist nel mio gh-pages ramo

Answer 1

Sì e no.

Sì, è possibile condividere sottodirectory tra filiali - git fa tutto il tempo.

No, non è possibile mantenerli sincronizzati automaticamente con i normali comandi git.

Purtroppo, non sono vicino a una shell in questo momento, quindi non posso fornire i comandi, ma ti mostrerò la strada.

Git ha tre strutture dati fondamentali:

• blob sono oggetti che contengono gli effettivi flussi di grezzo di byte dei file o altre cose.
• alberi sono oggetti che descrivono una directory, proprio come in un normale file system. Essi contengono gli hash delle macchie insieme al loro nome, modalità ecc
• commette sono oggetti che contengono l'hash di un oggetto albero e informazioni di vario genere, come autore, data e ora, genitore commette ecc

Questi tre le cose sono letteralmente ciascuna un file all'interno di .git/objects, con un nome file uguale al loro hash del contenuto.

Per il tuo problema, la chiave è che questi oggetti costruiscono un grafo aciclico diretto di sola lettura proprio come sei abituato a commettere.

Sei interessato agli alberi. Dopo aver giocato con git cat-file, puoi dare un'occhiata ad alcuni oggetti dell'albero. Noterai immediatamente come risolverebbe il tuo problema se fossi in grado di hackerare il tuo albero _include in modo che contenga puntatori agli alberi da quell'altro ramo. Nota che a questo livello profondo è del tutto naturale condividere gli alberi tra commit e branch, git fa tutto il tempo. Tra gli altri, questo è il motivo per cui gli archivi occupano uno spazio relativamente piccolo e anche perché git è talvolta chiamato un file system distribuito.

Ora, ci sono due avventure a sinistra per voi stessi:

• trovare il modo di fingere un albero che sembra si voleva. Come ho già detto, non ho una shell ora, ma dovresti essere in grado di capirlo con gli esempi in https://git-scm.com/book/en/v2/Git-Internals-Git-Objects che mostrano come leggere e scrivere singoli oggetti.
• Sfortunatamente, a causa della natura di queste strutture di dati di sola lettura, è necessario ricostruire l'albero _include ogni volta che uno degli alberi inclusi cambia, poiché questo darà loro anche nuovi hash. Probabilmente lo avete indovinato - nulla può mai effettivamente cambiare qualsiasi oggetto git. Le modifiche vengono sempre apportate creando nuovi oggetti. Questo non dovrebbe essere un grosso problema, tuttavia puoi creare un hook appropriato per il tuo script che crea automaticamente un nuovo albero per te.

Francamente, però, affascinante come tutto questo è, si potrebbe altrettanto bene dimenticare tutto quello che ho appena detto e semplicemente ricreare il _include da zero con comandi git porcellana in un gancio ogni volta un commit tocchi le directory di origine, da controllandoli dal ramo di origine, copiandoli poi (con cp, non un comando speciale git) e comandoli nel ramo di destinazione. Git sarà in realtà automaticamente capirai che quelle sottodirectory sono le stesse di quelle che avevano già nei rispettivi oggetti, quindi il risultato finale sarà esattamente lo stesso di se tu stesso abbia creato l'oggetto albero!