What's The Normal Process For Using Version Control?

[finnegan]

The company I work for is hosted by a company who is using version control so that any changes we make on production have to be relayed over so they know what is changed on our end. That way, it won't be overwritten when they push something from staging to production a week later.

To me though, it seems crazy that I need to notify my hosting company every time I fix a broken link directly on the site or do any onpage SEO work.

Isn't there a way to have version control and still be able to make small changes, fixes without having to notify your hosting every time you do it?

 

[turbin3]

That sounds like a strange hosting paradigm. I'm guessing it's some sort of managed hosting. Do they not allow access to the version control?

Normally what you'd want to do is make changes to a local branch, then submit a pull request, it would get merged to the master (on their end it sounds like), and then they'd push to production. Normally the flow is something along these lines:

Branch → Master → Production

Or for more complex stuff maybe even:

Feature Branch → Branch → Master → Production

 

[Philip J. Fry]

Not crazy at all. Here's what you do.

You either set up a date where SEO's gonna push its content (ie ever 7th of the month) and queue all updates on the 6th and then push on the 7th. That way, you make the call once every month.

Or, go through the site and get everything perfect once, do the push, and move on.

I used to work for the Government and, trust me, it can get more backward and inconveniente. A good UX is only needed for the customer. Stuff like security, reliability, and "easy to develop" are much more important for employee users.

 

[Joe]

The whole idea of staging is to shield production from "this quick little change" from someone that accidently breaks stuff.

If you're your own company, you can push to production whenever you want. The 7 days they set is probably for testing the previous staging before putting it into production. It's just quality control. A small project can make do with just dev to production on an ad hoc basis (many bloggers for instance only use production alone), but bigger projects will have even more stages.

And as always people can get ahead of themselves, making a big multi stage quality control process before they even have a customer. Managers get hard ons for "process" as it justifies their job even when it's overkill. As always, everything should be in balance.

So yeah just push to staging and move onto the next task.

 

[Rageix]

Basically what Joe said. Seems like there is a hierarchy in place, which is not uncommon on bigger projects and if you don't have the rights to merge into your production branches, then you're SOL.

Most bigger projects have a setup like:
Production <- Staging <- Work branch

It can, of course, be much more complicated than this depending on the project, but in such setups, there is probably someone in control of merging all the work into Staging, then reviewing it, and then actually merging all the work into production and sending it off.