I'm trying to tidy up the Git repositories for the few sites that I maintain. For each site, I usually create a separate branch in the repo that holds a "maintenance page" or "holding page", which I checkout if I need to take the site down for any reason. This branch is usually called
maintenance_page. Normal development is done against
master and the live site is also deployed from there.
Whilst the site code in the
maintenance_page branch has the same styling as the main (live) site in
master, it doesn't really share any history with the master branch - think of it like a mini version of the live site, but with it's own basically unrelated codebase. From time to time, changes that I make to the styling, images, etc. in
master would be useful to have in the
maintenance_page branch and in these situations, I usually
git cherry-pick from
I've been working with this setup for a while now, however, I'm conscious that the whole idea of having the two branches (
maintenance_page) coexisting in the same repository, but not having anything really in common with each other is not really the "Git way of doing things". I've thought of storing the
maintenance_page branch in it's own repo (as it has very little in common with the master branch), however this just seems to complicate the administration of the repositories and also detracts from the simplicity of being able to simply checkout the
maintenance_page branch, when I need to take the site down elegantly.
I've had a good read around (see here) (and here) to try to find out how other people handle this kind of thing, but I'm strangely unable to come up with any pointers on how other achieve this.
Does anyone have any suggestions on better ways to achieve this?