I have a website that i keep in git. It is a asp.net webforms website (but that is probably unimportant to this question).
The website is used by our customer for 2 (in
Assuming that your master branch contains your entire project:
|--BackOffice
| \--UI
|--BackOffice.UI
| \--WebControls
|--BackOfficeTests
|--Deployment
| \--db
|--BusinessLogicLayer
| |--bin
| |--obj
| \--Properties
|--scripts
|--Website
| |--admin
| |--App_Browsers
| |--App_Code
| |--App_Data
| |--Styles
| |--web.config
Now, any change which is common to all websites, gets committed to this branch.
Make separate branches for various sites. Example:
From the master branch,
git checkout -b site1
git checkout -b site2
git checkout -b site3
git checkout -b site4
now whenever you want to change any site specific files, i.e. Styles folder or web.config, do it in these branches.
Now comes the deployment part. Suppose you want to deploy site1, create a temporary branch on local system based off master, merge site1 branch into it and deploy it. Finally delete the temp branch.
git checkout -b temp
git merge site1
tar or zip your code and deploy it. After that,
git checkout master
git branch -D temp
You can even make a small shell script that does that if you do not want to expose the way deployment is done. Lets call this script deploy.sh For example:
#!/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
Now when you say ./deploy.sh site2, this script will do all dirty work behind the scenes and give you a tar file which you can deploy on production server.
I hope this is helpful...
A submodule is a good solution for the shared BackOffice code, with each site acting as a parent repo.
But that doesn't address the config files.
For those, one possibility is a content filter, but that would involve storing and pushing the values of the variable for the different clients.
It is best to keep those config files in the parent repo in client-specific branches.
I might make separate "Site" and "Common" directories, with "Common" containing symlinks at strategic points and one or both a submodule, like so:
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
That's not the only layout that would serve -- for instance, if it should be easy to have different sites pick and choose what gets tweaked you could preserve your current layout, adding the "Common" subproject and symlinking anything you use from it unchanged, like so:
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
The more I look at it the more I like that last one better.