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 the future 4) websites. Most of the functionality is shared. But a few things like web.config and a folder with css is unique for each website.
Here is a simplified version of the code
|--BackOffice | \--UI |--BackOffice.UI | \--WebControls |--BackOfficeTests |--Deployment | \--db |--BusinessLogicLayer | |--bin | |--obj | \--Properties |--scripts |--Website | |--admin | |--App_Browsers | |--App_Code | |--App_Data | |--Styles | |--web.config
What would a good structure for this be in Git?
For instance the BackOffice code would be completely shared. The Website would be shared except for the Styles folder and the web.config file.
Do you have a good suggestion for a structure that does not make merging and branching too long haired?
I have tried to make a structure like so:
Master |--Site1 |--Site2
But I foresee too much cherrypicking when moving code from one branch to another Would a submodule be ok or would it complicate things?
EDIT: My really big problem is that I want to deploy directly from my git repo. And if I leave in these directories / files they will be merged during merge, unless i do some complicated stuff (then I cant let everybody on the team do this). Or I will have to ignore these files and get them from somewhere else...
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...
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With