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 master to maintenance_page.
I’ve been working with this setup for a while now, however, I’m conscious that the whole idea of having the two branches (master and 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?
3
As MainMa already said, the maintenance page is a feature of the site. They are not two sites. The maintenance page is a special page of the site and should therefore go with it in the same tree.
Branches are great for parallel history, but not suitable for about anything else. For different variants, the only practical way is having them together in the tree and use some kind of conditional inclusion. I work on project (not web, but the principle is the same) that delivers slightly different versions for more than 10 customers on 5 different platforms. With conditional compilation this works fine, branches would have devolved into madness long ago. In case of web site, the conditional inclusion is controlled by server configuration.
Note that there is no ‘git way of doing things’. Just ‘version control best practices’ that apply to all version control systems whether you use git, subversion or directories, tarballs and patches (like Linus did for 10 years before he wrote git). And these say that branches are for parallel history, not parallel variants. Git makes branches easier to use, but that does not mean they would suddenly become appropriate for things they were not before.
Since the maintenance page is a feature of the web application, there is no reason to put it into a separate branch or repository. Instead, have a dedicated directory, or maybe even just a file at the root. This will make it possible to:
-
Share all static files such as the images, CSS or JavaScript,
-
Benefit from common code instead of duplicating it with the risk of the maintenance page being not properly updated when the web application itself changes.
You probably won’t be able to share everything, especially since, I presume, your web app uses templates while the maintenance page is static, but it’s still much less hassle than to maintain a different branch or repository.
You can then switch between the web application and the maintenance page by changing the configuration of the server (like an automatic redirection of any GET request other than favicon.ico and robots.txt to the maintenance page, and an HTTP 500 for POST requests).
Note that when your web application will grow, you’ll be looking into more user-friendly ways to put your web app on maintenance anyway. This includes:
-
Having a read-only flag, similar to Stack Exchange read-only mode which prevents any one to log in and post, comment and upvote.
A similar technique is used on other large websites as well; for example, on B&H, one of the largest e-commerce websites for photographers, you are sometimes unable to purchase products, while you can still browse the catalog.
-
Having solid infrastructure which makes it possible to bring one server offline, do maintenance on it, bring it online, and do the same thing with another server.
This approach is more advanced, since it doesn’t disturb the end users: for them, the website is always online, and all the operations they were doing when being switched from one server to another are preserved.
8