Git, sub-repos e librerie esterne per lo sviluppo web: la migliore strategia una volta per tutte?

Question

Questo è uno scenario comune che ci deve essere una soluzione ragionevole, ma nonostante le pagine di lettura e di ginnastica Git copiose, i miei dolori cerebrali e io sono in grado di fare questo lavoro ...

sto lavorando con Wordpress, anche se questo si adatta alla maggior parte degli scenari di sviluppo di siti web. Voglio gestire l'installazione del sito con un repository git e anche gestire vari plugin WP, plugin jQuery e altri bit di codice in repository separati che possono essere facilmente estratti/spinti dalle loro fonti esterne. Sembra abbastanza semplice fino a quando si guardano i dettagli ...

I criteri

"sottocartelle" criterio La cartella per ogni plugin non deve essere vincolato alla cartella principale della sua repo fonte. Molti repository hanno più cartelle nidificate come "my-repo-name/...", "dev /", "test /", "src /" dove il contenuto della successiva è la cosa richiesta. Questo è importante per mantenere gli URL di riferimento puliti e per ridurre al minimo la spazzatura pubblicamente disponibile.

"No Proxys" criterio La soluzione ideale non richiederebbe ulteriori filiali intermedie o repository. Spingere le modifiche alla fonte esterna di un plug-in dovrebbe essere semplice e non richiedere più operazioni di unione/push intermedie.

"Real Files" criterio Idealmente repo esterna per tutto il sito deve effettivamente contenere i file del subrepos i plugin (cioè non 'sottomoduli'). Potrei essere convinto da questo però ...

"Pubblicazione" criterio Deve giocare bene con rsync e/o git push'ing al server di vivere

Ho guardato questi cinque soluzioni

Git moduli abbastanza semplice per apportare modifiche e spingendo/tirare ma sottomoduli fallire sui "sottocartelle" e criteri "reale file"

Git lettura-albero/subtr ee merge Risolve il problema "Real Files" e read-tree in realtà consente di fare riferimento alla sottocartella di un ramo, ma quando l'ho fatto e ho provato a unire le modifiche sul master backstream, Git non è riuscito a ricordare che proveniva da una sottocartella e l'intera struttura del master incorporato in il ramo di monitoraggio ext libs ... quindi FAIL su questo criterio.

Apenwarrs sottostruttura estensione (here) Grande per il criterio "Files reale" e abbastanza semplice da spingere/tirare fino a quando si desidera applicare la regola "sottocartelle". Nella migliore delle ipotesi sembra quindi che siano necessari rami intermedi in cui dividi la cartella che desideri dal ramo di monitoraggio remoto e quindi aggiungi questo come sottostruttura al tuo ramo principale. Non ho avuto molta fortuna unendo/spingendo i cambiamenti sul master al repository di origine. Io continuo a pensare che ci possa essere la possibilità qui ...

link simbolici con repo esterno grande soluzione fino GIT fermato seguenti link simbolici.Ora non riesce a "Real Files" e criteri di "pubblicazione"

repos nidificati Da qualche parte ho visto un SO rispondono dove se esplicitamente git add una cartella che contiene un altro repo e includere la barra finale, git sarà NON modulo è ma invece traccia i singoli file. Questo sembrava promettente, ma fallisce nel criterio delle "Sottocartelle".

Cosa succederà?

Ho visto riferimenti a "check-out sparsi" - o forse qualcosa che coinvolge la potatura del ramo. Spero di evitare una soluzione che implichi script di shell o sia così complessa da richiedere di re-apprenderla ogni volta (poco frequente) apporto una modifica a un plug-in. Deve essere più facile che mantenere un repository separato per ciascun plug-in e copiarlo avanti e indietro dall'installazione principale di CMS.

Sicuramente qualcuno ha un modo semplice e funzionale per far funzionare questo scenario di sviluppo comune ?? Grazie in anticipo per l'aiuto ...

Answer 1

Chiaramente hai pensato a questo, e io sono solo un novizio di git, ma il mio primo istinto sarebbe quello di aggiungere .gitignore alla directory dei plugin e avere ogni plugin hanno è il proprio repository git. Potresti fare lo stesso per i temi. Quindi immagino che sia più una domanda che una risposta - perché questo semplice approccio non dovrebbe funzionare?

Answer 2

Non so se questo risponda alla tua domanda per intero, o addirittura copra il tuo scenario specifico, ma ho pensato di fare un tentativo in ogni caso.

Abbiamo diversi progetti, molti dei quali si riferiscono l'un l'altro, ciascuno nel proprio repository Git. Sono anche contenute in più livelli di cartelle, ad esempio:

Repos 
    - Utilities 
     - Util repo1 
     - Util repo2 
    - Common 
     - Lib repo1 
     - Lib repo2 
    - Projects 
     - Client1 
      - Git repo1 
      - Git repo2 
     - Client2 repo 
     - Client3 
     ... 

abbiamo avuto un problema con dover manualmente spingere/tirare/commit ogni repository, che è diventato un incubo.

Così abbiamo scritto un piccolo programma di utilità che è in grado di fare spingere, tirare, impegnarsi, tag, diff remoto e diff operazioni Git su più cartelle alla volta, così come creare più VS file di soluzione allo stesso tempo. Controllerà anche nelle sottocartelle i repository.

Lo stiamo usando da un po 'di tempo e funziona perfettamente per noi. È possibile verificarlo da qui: Gitter.7z

Aprire il file ReadMe.html per vedere come utilizzarlo. Spero che questo aiuti, fammi sapere.