How does one store a website's holding/maintenance page in Git? - Software Engineering Stack Exchangemost recent 30 from softwareengineering.stackexchange.com2019-09-15T10:50:21Zhttps://softwareengineering.stackexchange.com/feeds/question/251361https://creativecommons.org/licenses/by-sa/4.0/rdfhttps://softwareengineering.stackexchange.com/q/2513611How does one store a website's holding/maintenance page in Git?JoeNylandhttps://softwareengineering.stackexchange.com/users/1433052014-07-19T14:47:55Z2014-07-28T09:06:56Z
<p>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 <code>maintenance_page</code>. Normal development is done against <code>master</code> and the live site is also deployed from there.</p>
<p>Whilst the site code in the <code>maintenance_page</code> branch has the same styling as the main (live) site in <code>master</code>, it doesn't really share any <em>history</em> 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 <code>master</code> would be useful to have in the <code>maintenance_page</code> branch and in these situations, I usually <code>git cherry-pick</code> from <code>master</code> to <code>maintenance_page</code>.</p>
<p>I've been working with this setup for a while now, however, I'm conscious that the whole idea of having the two branches (<code>master</code> and <code>maintenance_page</code>) coexisting in the same repository, but not having anything <em>really</em> in common with each other is not really the "Git way of doing things". I've thought of storing the <code>maintenance_page</code> 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 <code>maintenance_page</code> branch, when I need to take the site down elegantly.</p>
<p>I've had a good read around <a href="https://www.kernel.org/pub/software/scm/git/docs/gitworkflows.html#_managing_branches" rel="nofollow">(see here)</a> <a href="http://gitolite.com/archived/branches.html#product-maintenance" rel="nofollow">(and here)</a> 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.</p>
<p>Does anyone have any suggestions on better ways to achieve this?</p>
https://softwareengineering.stackexchange.com/questions/251361/-/251364#2513643Answer by Arseni Mourzenko for How does one store a website's holding/maintenance page in Git?Arseni Mourzenkohttps://softwareengineering.stackexchange.com/users/66052014-07-27T17:56:57Z2014-07-27T18:02:52Z<p>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:</p>
<ul>
<li><p>Share all static files such as the images, CSS or JavaScript,</p></li>
<li><p>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.</p></li>
</ul>
<p>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.</p>
<p>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 <code>favicon.ico</code> and <code>robots.txt</code> to the maintenance page, and an HTTP 500 for POST requests).</p>
<p>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:</p>
<ul>
<li><p>Having a read-only flag, similar to Stack Exchange read-only mode which prevents any one to log in and post, comment and upvote.</p>
<p>A similar technique is used on other large websites as well; for example, on <a href="http://www.bhphotovideo.com/" rel="nofollow">B&amp;H</a>, one of the largest e-commerce websites for photographers, you are sometimes unable to purchase products, while you can still browse the catalog.</p></li>
<li><p>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.</p>
<p>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.</p></li>
</ul>
https://softwareengineering.stackexchange.com/questions/251361/-/251403#2514030Answer by Jan Hudec for How does one store a website's holding/maintenance page in Git?Jan Hudechttps://softwareengineering.stackexchange.com/users/382002014-07-28T08:49:40Z2014-07-28T09:06:56Z<p>As MainMa already said, the maintenance page is a feature of the site. They are <em>not two sites</em>. The maintenance page is a special page of the site and should therefore go with it in the <em>same tree</em>.</p>
<p>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.</p>
<p>Note that there is no '<em>git</em> 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, <em>not</em> parallel variants. Git makes branches easier to use, but that does not mean they would suddenly become appropriate for things they were not before.</p>