How to structure git for production and development webserver environment?

Hi folks,

I am new to Git and am trying to learn it and implement it in my environment at the same time. I’ve spent a week reading, watching videos/tutorials and following their guides but still can’t figure out how to implement Git in a webserver environment.

I have two servers both running apache, both serving the same website.

I want to make my edits on the dev box and then push them over to the production server.

So far I’ve tried creating two separate repos, one on each box, but I get messages in gitbash about not being able to push into a non-bare repo when I try and push from the dev-box repo to the prod-box repo.

Then I tried creating a bare repo on the production box instead, and I could successfully push those files… but it’s a webserver, and so there were no files being served in the web directory. Http://production/ displays nothing because it’s a bare repo.

So then I tried cloning that bare repo into a /htdocs/ repo so that I had physical copies of files to be served by the webserver.

That so far seems to work. I can now make edits on the development box, push them to the production server, then from the production server, pull them into the cloned repo from the bare repo. So far so good!

My next dilemma is that two people work on the development box, each making changes that should be separately tracked so as not to commit someone else’s half-complete code on to the production server.

So I created branches on the development box, one for each person, but whenever I checkout a branch, it replaces the content in the physical files which means one person’s edits will only ever be visible by browser at the http://development/ URL at a given time, and that won’t work.

So then I tried to clone the dev repo into two separate repos, one for each person. Now making each persons’ edits visible at http://development/personA and then http://development/personB, but same problem as before, I can’t push edits to files into the non-bare dev-repo!

Hopefully it’s apparent that I am lost!

I can’t figure out how to set up my repos. Clones? Branches? Bare repos? Which one goes where?

To summarise:

I have two servers:

  • a production box that displays live content

  • a development box that displays the same content and is edited by two people

  • each person should be able to see their edits via HTTP on the dev box, and should be able to then push the http://development repo over to the http://production/ repo when they’re ready

If anyone could suggest how I should set up my repos I would be very very grateful

2 Likes

Hi @leegil,

What I would recommend is having a single repository that represents your website with a couple of different branches. You could use a production or master branch for serving the production site. Then you could have a development or a testing branch where your developers could integrate their changes and do testing before merging them into production. For the developers to do their work, you could have each of them have a separate branch where they work on their own specific parts of the project which they can then merge into your development or testing branch once their section is complete.

I know that this is a very incomplete answer and others in the community might be able to give you a more complete breakdown of how you could structure this project. In the meantime, you may be interested in the GitHub Guides which have examples of how a Git project can work and the GitHub Learning Lab which is a hands-on tool for learning the ins and outs of Git and GitHub.

Thanks!

4 Likes

@that-pat wrote:

For the developers to do their work, you could have each of them have a separate branch where they work on their own specific parts of the project which they can then merge into your development or testing branch once their section is complete.

Thanks for your reply that-pat, that’s what I’ve done and it sounds good in theory but it doesn’t seem to work in practice? 

When a developer ‘checks out’ their branch, apache starts serving those files and so that developer’s changes are available via http://. But other developers can’t look at their changes via http until their own branch is checked out.

Apache is serving whatever branch is checked out at the time, but that means noone else can look at the website and check how their code is displaying. So only one person can work on it at once.

I must be missing something really obvious because I’ve been googling and noone else seems to be having this problem, so I must be overlooking something? How can multiple users each checkout their own branch and have their modifications seen simultaneously via http://?

1 Like

Hi @leegil,

For the development server issue, I’ve found one option that can work well is having each developer run a local server on their machine rather than using one central development web server. This will allow multiple developers to see how their code works on the website (through their local machine) and then they could push the changes from local development through to production.

Would something like that work for you? In case it helps, there are tools like ngrok which could be used to share local development with other people (for example, a developer codes a feature on their machine, then sends you an ngrok link so you and other folks can view the work) before the work is pushed to production.

​If there’s anything else I can help you with, let me know; so happy to help further!

Thanks matthew, I wouldn’t get away with that unfortunately as running services on devices outside of the firewalled server environment is a no-no. My company are quite strict on various things due to the nature of the industry, and running potentially exploitable software on a desktop would come back to bite me.

But I think I’ve found something that works. I’ve created a bare repo at /apache/git and pushed a commit from a temp repo of /apache/htdocs and then created directories at /apache/htdocs/personA and /apache/htdocs/personB with cloned repos of /apache/git, which sets it up as a remote even though it’s on the same server.

Each person can then work on their changes, view them at their url and then push them to the bare repo, where the other person can fetch/pull them into their own repo.
When either person wants to publish their work, they can jump on the production server and pull/fetch from the repo.

I should be able to create each person’s repo outside of the /htdocs/blah path so they’re not being served, as per how the /apache/git directory is.

Thanks for your help, folks. Thinking the problem out loud has definitely helped. :slight_smile:

3 Likes

leegil, did you ever come up with a solution to this?

I have a similar scenario: I have a Classic ASP developer on my team, and all he’s ever used is VSS.  He works exactly as you describe: The “test” server is his “repo”, and when he’s ready to move the code to “prod” he copies it over with a compare-and-move utility.  To complicate things, two people contribute to this “repo”.

I’ve been trying to use Git to replace VSS in this context and have so far fallen flat.  I can get no help online, because the people who know Git only offer suggestions that involve mulitple branches, tags, local repos, etc, all of which are beyond the two developers I have, one of which is even adamantly against anything command line driven.

I tried simply creating a Git repo at that level, and copying in those files, but it made “me” the owner, and the other devs can’t interact with the repo. 

I’m not sure there is an answer in my case.  Source code control systems have become complex, and in this case, my developers have not kept up.  I have read hundreds of similar cases online, where people don’t know how to use Git but do so anyway, without really understanding what they’re doing, leading to many issues.  Lots of questions similar to these, asking to simplify the use of Git for this type of user, but I have not seen an answer that doesn’t make it ever more complex.

1 Like

Cannot delete, apologies for the necro post

Your setup seems very common. You should have a look at Git Flow. It simplifies the development process and does a lot of the underlying commands for you. If you use VS Code, there are plugins that integrate Git Flow into it.

FWIW to others sharing leegil’s original question/concern, and in response to the last reply here (by kurdtpage), I’ll point out that as far as the recommendation of git flow, its creator (Vincent Driessen) acknowledged just a month later (on the very page pointed to by that link they shared about Git Flow) that it’s not a good fit for most web app development. He updated the top of the page in March saying:

"This model was conceived in 2010…and the most popular type of software that is being developed with Git is shifting more towards web apps…[which] are typically continuously delivered, not rolled back, and you don’t have to support multiple versions of the software running in the wild.

This is not the class of software that I had in mind when I wrote [this git-flow] blog post 10 years ago. If your team is doing continuous delivery of software, I would suggest to adopt a much simpler workflow (like GitHub flow) instead of trying to shoehorn git-flow into your team."

Of course, a casual reader could miss the distinction being made is between Github Flow vs Git Flow/git-flow. I’ll let you read the links offered to see the differences. And I don’t raise it as the solution to the OP’s concern, myself.

Like leegil and some others here, I am surprised by the relative lack of coverage of how best to handle small team web app deployment scenarios like they’ve laid out, so I hope this discussion here may continue and evolve. I suspect someone may have a great resource to recommend. I keep looking for it, myself, to share with others in the same boat (whatever web app tech they may be using).

Apologies for the slow reply to some of the above messages, the email notifications for those posts might have landed in my spam folder.

This is what I did in the end and it has been working for the past couple of years since I created this topic.

Please keep in mind that it may not be best practise, there may be other and better ways to achieve the same thing but at the time I couldn’t find them and it was holding up my project.

The above diagram should explain the structure I used but basically I had two servers, one for production and one for development. For company policy and firewall reasons, developers couldn’t run their own repos on their local machines, it had to be limited to the development environment, so all the developer’s repos are in separate folders on the one development server.

The production server has just the one repo at the appropriate apache folder so that it’s serving those files publically.
The development server has a BARE repo, located anywhere, but in my case it’s at C:\Apache24\git and is not being served up by apache, and it’s basically the central repository between all developers.

Each developer then has a clone of the central bare repo at C:\Apache24\htdocs\usersNameGoesHere and that is then their repo that they work with.

This results in:

  • Each developer having their own repository so they can keep and check out their own branches without affecting other users
  • Apache serving up everyone’s files at all times so those website versions are available both locally from the server or from elsewhere in the network, just by altering the URL to include the developer’s path.
  • Everyone else (even non-developers) being able to navigate to http://development.com/usersNameHere/whatever.php to check out what they’re working on. Apache will start serving whatever branch has been checked out for that developer at that time. When they check out a different branch, apache will start serving those files too.

The one downside to my setup is that apache isn’t serving up the central repository so I can’t browse the full dev website with EVERYONE’s changes prior to publishing. Because it’s a bare repo there are no files for apache to publish. It hasn’t hindered me too much as I can pull the other developer’s changes into my repo and browse my own URL to look at it.

Once each developer is done with their changes, they push it back to the central repo which makes it available for the other developer/s to pull down to their own repo.

When all of the changes are ready and the production server needs to be updated so as to start publishing those files at www.production.com, I jump on the production box and git pull them from the central bare repo on the development box. I’m not sure if this is the “right” way to do it… I thought I was supposed to be able to issue a “git push” into the production server while logged on the development server within its central repo but at the time I couldn’t get that working. so instead I log on to the production server and issue a git pull which pulls the updated files from the development server, into the production server’s repo. It seems backwards and it may well be, but it works.

As a final word, with this configuration it’s very important to lock down your apache config to prevent access to the git repo
Else anyone can just clone your git repo through your website’s URL and pull down all your code.

Hopefully that helps others who find this page down the track. There will probably be better ways to do this so if you find one, please post it here! :slight_smile: