Background: I've recently inherited a set of projects at my company and I'm trying to sort out some fundamental issues with how they've been handled. Namely, the previous developers (who are no longer with the company) were not using any form of source control, made little documentation, and didn't really have any good development processes in place.
So now I've got three servers worth of projects (development, staging, production) which consist of mostly websites and applications and tools built for third-party applications and APIs we use, down to stores of SQL scripts and other things. My first thought was to get all of this into Git before changes and fixes are made, but I'm having a difficult time figuring out the best way to do it.
A lot of previous development was done directly on the production servers, which has created a divide between each server's code base. It's not immediately clear where all the differences lie - I'm seeing bug fixes on the production side that aren't carried over on development/staging, as well as new features on the development that haven't been moved up towards staging/production.
Question: What would be the best way for me to organize and move these into Git? How would I structure my repos/branches to accommodate the differences in the code?
I've considered continuing development from clones of the production server code and keeping the development/staging code bases as historical reference. Would this potentially be a point to start with, considering I don't know anything about the dev/staging code anyway? I could simply create repos of the production servers for each website, tool, script set, etc., create branches for the existing dev/staging code, and any new development would branch from the production server's code base. Does this make sense?