2 Translated the last sentence to proper England
source | link

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?

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 this?

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?

    Post Migrated Here from stackoverflow.com
1
source | link

How does one store a website's holding/maintenance page in Git?

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 this?