The small website I built a long time ago is starting to pick up a little and I'm starting to run into problems with making changes. Originally, all the pages were .html and I would edit and test them offline to make sure everything worked. Then I realized how helpful php includes were, so I changed everything to .php and used includes. Without apache, I could no longer test offline, so with Filezilla, I would choose the "view/edit" option on files that were already on the server, edit them, and then have them uploaded again. This is what I've been doing so far and it's worked pretty well for the most part. I just save the temp file that filezilla creates, and let it upload it back to the server.
Yesterday, I realized that one of the javascript files I had worked on the day before had been replaced by an empty file. This was something to do with sublime text keeping the non-existent temp file open/filezilla uploading an empty file – I'm not really sure what happened, but it shouldn't have been able to happen. And now, I need to change the design of the site, and doing that one page at a time would be noticeable, so I need to do it offline first.
I would like to use version control and install apache so that I can completely test my site offline, but there are a couple problems I have with this. The first is that I have a Forum on the site. I could install mysql and export the tables, then import them offline, but then, while people are making posts on the website, the offline copy becomes out of date and I can no longer upload that back to the server. I also have some Python scripts on the site using WSGI. My webhost's settings are very specific, so if I wrote python scripts offline and ensured they were working, I wouldn't know if they were going to work online.
Should I edit everything offline and upload it all back to the server when it works? What happens if a php or python script executes one way on my local machine than on the server?
Best Answer
Version control will only help to the extent that you will be able to go back to previous (hopefully working) versions.
It will not help with botched deployments and changes.
You need to have a test environment - a web server that you can put the changes on and test them and only when happy, push to a live (publicly visible) web server.