Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

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?

share|improve this question

migrated from stackoverflow.com Jul 27 at 17:10

This question came from our site for professional and enthusiast programmers.

2  
I've received no input on this question since I posted it. If I can improve the question in some way, please let me know. I'm beginning to wonder "Have I asked this question in the correct place?" –  MasterRoot24 Jul 25 at 10:48
    
As I suggested above, I requested that this be migrated to programmers. Again, if I can improve the question in some way, please let me know. –  MasterRoot24 Jul 27 at 21:04
    
To the silent down-voter: Please explain why you have down voted. –  MasterRoot24 Aug 2 at 7:18

2 Answers 2

up vote 0 down vote accepted

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.

share|improve this answer

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.

share|improve this answer
    
Thanks for your answer! You're correct, for the web apps that I'm developing I would build this kind of thing into the web app itself. However, my question is meant more for static sites, really -- maintaining [essentially] two sites in one branch (live site and holding page), as you suggest just doesn't seem to sit right with the 'Git way of doing things', IMO. –  MasterRoot24 Jul 27 at 20:26
1  
@MasterRoot24: It does not matter whether the site is static or dynamic. The first sentence answers your question and does so generally. Branches are great for history, but not suitable for about anything else. Not specifically in git; in any version control system. –  Jan Hudec Jul 27 at 20:46
    
@JanHudec: Thanks for your input too. I understand that it's irrelevant whether the site is static or dynamic. However, my issue with this answer is (as I have said in my last comment): Two sites in one branch (live site and holding page) doesn't seem to sit right with the 'Git way of doing things', in that having the live site and holding page in one branch is like having two 'features' in one branch, thus there is no way of cleanly switching between the two sets of code, without depending on server side redirects. Then things start to get messy... –  MasterRoot24 Jul 27 at 21:03
    
@MasterRoot24: They are not two sites. The holding page is a special page of the site itself. And therefore goes in the same tree. –  Jan Hudec Jul 28 at 5:09
    
@MasterRoot24: Having two "features" in one branch is the only practical way. I work on project (not web, but it does not really matter) that delivers slightly different versions to more than 10 different customers on 5 different platforms. All the releases are always done from the same branch using conditional compilation and it works fine. Branches would have devolved into madness long ago. –  Jan Hudec Jul 28 at 5:15

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.