Utilizzo di più versioni di siti Web (Git)

Quello che potresti voler vedere è che più repository sono qui biforcati fuori da una linea principale di template di sviluppo. Ciò ti consente di mantenere alcuni modelli centralizzati mentre lascia che i progetti downstream mantengano un po 'più di controllo sul proprio destino, includendo anche le patch nel core se hai bisogno di rotolare in quel modo.

Abbiamo usato una strategia di questo tipo per una mezza dozzina di siti wordpress con grande effetto, potremmo ottenere aggiornamenti della sicurezza dei dipendenti distribuiti su tutti i progetti in pochi minuti. Vorrei echeggiare @Aaronaught qui - a meno che tu non sia molto disciplinato nel modo in cui sviluppi il modello principale, questo sarà difficile da ottenere. Wordpress, nel corso degli anni, ha ottenuto quella disciplina, quindi ha funzionato benissimo.

Penso che tu stia confondendo il ruolo del controllo del codice sorgente con il ruolo dell'architettura software e della corretta gestione delle dipendenze.

Se hai un sistema di template, o solo un template, che vuoi essere in grado di implementare su più siti, lo puoi progettare come un framework standalone che può essere personalizzato in determinati modi prevedibili. Ecco come funzionano già i CMS come WordPress. Se è necessario modificare il modello e si desidera propagarlo a tutti i siti, è sufficiente rilasciare una nuova versione del framework e aggiornare i siti basati su di esso.

La clonazione di un repository è intesa principalmente come uno strumento per far lavorare più sviluppatori sullo stesso progetto . Penso che ti imbatterai in molti mal di testa in un futuro più lontano se proverai a usare quel modello per lavorare su diversi progetti diversi . Senza l'incapsulamento fornito da un framework reale, è quasi certo che verranno apportate modifiche ai siti basati su modelli che essenzialmente li bloccano, e mentre questo è sempre un rischio, è esacerbato qui dall'ambiguità tra modifica ed estensione, una chiara violazione di il principio aperto-chiuso . Mentre questo principio è specifico per OOP, il concetto generale si applica a tutto il software.

I rami probabilmente costituirebbero un modello che è più facile da capire, anche se tecnicamente in Git puoi ancora fare tutte le stesse cose con più repository, anche se in modo più goffo, semplicemente aggiungendo quelli locali come telecomandi . Non sono sicuro del motivo per cui vorresti, ma è possibile.

Tuttavia non è un buon progetto. Al fine di mantenere i siti mantenibili, si desidera una chiara separazione delle preoccupazioni tra framework / modelli, contenuto / personalizzazione e distribuzione del sito. Sembra che tu le stia combinando tutte e ti esorto a riconsiderare prima di adottare un approccio rischioso e soggetto a bug che dipende interamente dal controllo del codice sorgente. Git è ottimo ma non perfetto, e anche quando un'unione ha 0 conflitti, può comunque interrompere il tuo sito se le modifiche in entrambi i repository sono significative.