Struttura in git con più siti web

Question

Ho un sito Web che tengo in git. È un sito Web di asp.net Webforms (ma probabilmente non è importante per questa domanda).

Il sito Web viene utilizzato dal nostro cliente per 2 (in futuro 4) siti Web. La maggior parte delle funzionalità è condivisa. Ma alcune cose come web.config e una cartella con css sono uniche per ogni sito web.

Qui è una versione semplificata del codice

 
|--BackOffice 
| \--UI 
|--BackOffice.UI 
| \--WebControls 
|--BackOfficeTests 
|--Deployment 
| \--db 
|--BusinessLogicLayer 
| |--bin 
| |--obj 
| \--Properties 
|--scripts 
|--Website 
| |--admin 
| |--App_Browsers 
| |--App_Code 
| |--App_Data 
| |--Styles 
| |--web.config 

Cosa sarebbe una buona struttura per questo essere in Git?

Ad esempio, il codice di BackOffice sarebbe completamente condiviso. Il sito Web sarà condiviso tranne che per la cartella Stili e il file web.config.

Hai un buon suggerimento per una struttura che non rende la fusione e la ramificazione a pelo lungo?

ho cercato di fare una struttura in questo modo:

 
Master 
|--Site1 
|--Site2 

Ma prevedo troppo cherrypicking quando si sposta il codice da un ramo all'altro Sarebbe un modulo essere ok o sarebbe complicare le cose?

MODIFICA: Il mio problema più grande è che voglio eseguire il deploy direttamente dal mio repository git. E se lascio in queste directory/file, verranno uniti durante l'unione, a meno che non faccia alcune cose complicate (quindi non posso permettere a tutti i membri del team di farlo). O dovrò ignorare questi file e ottenerli da qualche altra parte ...

Answer 1

Supponendo che il branch master contiene l'intero progetto:

|--BackOffice 
| \--UI 
|--BackOffice.UI 
| \--WebControls 
|--BackOfficeTests 
|--Deployment 
| \--db 
|--BusinessLogicLayer 
| |--bin 
| |--obj 
| \--Properties 
|--scripts 
|--Website 
| |--admin 
| |--App_Browsers 
| |--App_Code 
| |--App_Data 
| |--Styles 
| |--web.config 

Ora, ogni cambiamento che è comune a tutti i siti web, viene impegnata per questo ramo.

Creazione di rami separati per vari siti. Esempio:

dal ramo principale,

git checkout -b site1 
git checkout -b site2 
git checkout -b site3 
git checkout -b site4 

ora ogni volta che si desidera modificare qualsiasi file site specific, cioè cartella stili o web.config, fanno in questi rami.

Ora arriva la parte di implementazione. Si supponga di voler distribuire sito1, creare un ramo temporaneo sul sistema locale basato su master, unire il ramo site1 in esso e distribuirlo. Infine cancella il ramo temporaneo.

git checkout -b temp 
git merge site1 

tar o zip il codice e distribuirlo. Dopo di che,

git checkout master 
git branch -D temp 

Si può anche fare un piccolo script che lo fa se non si vuole esporre il dispiegamento modo in cui viene fatto. Consente di chiamare questo script deploy.sh Ad esempio:

#!/bin/bash 

if [ ! $1 ]; then 
     echo "Please pass in the name of the site you want to deploy." 
     exit 1 
fi 

#Check if we are on master branch 
git status | grep "On branch master" 
if [ $? -ne 0 ]; then 
     echo "You are not on master. Please execute 'git checkout master'" 
     exit 1 
fi 

#Check if the entered site for deployment actually exists 
git branch | grep $1 || { echo "No branch $1 exists for deployment."; exit 1; } 

#Update from remote 
git checkout -b temp 
git merge $1 
tar -cvf deploy-$1.tar ./deploy.sh * 
[ $? -ne 0 ] && echo "Some problem archiving the files..." && exit 1 
git checkout master 
git branch -D temp 

echo "Please use deploy-$1.tar file to deploy the site. Thanks." 

exit 0 

Ora quando dici site2 ./deploy.sh, questo script farà tutto il lavoro sporco dietro le quinte e vi darò un file tar che è possibile distribuire sul server di produzione.

Spero che questo sia utile ...

Answer 2

A submodule è una buona soluzione per il codice BackOffice condiviso, con ciascun sito che funge da repository padre.

Ma questo non risolve i file di configurazione.

Per quelli, una possibilità è una content filter, ma ciò implicherebbe la memorizzazione e la pressione dei valori della variabile per i diversi client.

È meglio conservare tali file di configurazione nel repository padre in rami specifici del client.

Answer 3

potrei fare "Sito" separata e directory "comuni", con contenenti link simbolici "comuni" in punti strategici e uno o entrambi un modulo, in questo modo:

Project 
|==.git 
|--Site 
| |--.git 
| \--Website 
|  |--Styles 
|  \--web.config 
\--Common 
    |--.git 
    |--BackOffice 
    | \--UI 
    |--BackOffice.UI 
    | \--WebControls 
    |--BackOfficeTests 
    |--Deployment 
    | \--db 
    |--BusinessLogicLayer 
    | |--bin 
    | |--obj 
    | \--Properties 
    |--scripts 
    \--Website 
     |--admin 
     |--App_Browsers 
     |--App_Code 
     |--App_Data 
     |--Styles -> ../../Site/Website/Styles 
     \--web.config -> ../../Site/Website/web.config 

Questo non è l'unico layout che avrebbe servire - per esempio, se dovrebbe essere facile scegliere siti diversi e scegliere ciò che viene ottimizzato è possibile mantenere il layout corrente, aggiungendo il sottoprogetto "Comune" e collegando tutto ciò che si utilizza da esso invariato, ad esempio:

Site 
|==.git 
|--BackOffice -> Common/BackOffice 
|--BackOffice.UI -> Common/BackOffice.UI 
|--BackOfficeTests -> Common/BackOfficeTests 
| [...] 
|--Website 
| |--admin -> ../Common/Website/admin 
| |--App_Browsers -> ../Common/Website/App_Browsers 
| [...] 
| |--Styles 
| \--web.config 
\--Common 
    |--.git 
    |--BackOffice 
    | \--UI 
    |--BackOffice.UI 
    | \--WebControls 
    |--BackOfficeTests 
    |--Deployment 
    | \--db 
    |--BusinessLogicLayer 
    | |--bin 
    | |--obj 
    | \--Properties 
    |--scripts 
    \--Website 
     |--admin 
     |--App_Browsers 
     |--App_Code 
     |--App_Data 
     |--Styles.example 
     \--web.config.example 

Più lo guardo più io come quello scorso meglio.