As with the others, I don't know of any great way to sort out the current situation easily, or an out of the box way to make it work super smoothly in the future although of course it does become somewhat smoother if you plan around this from the start when doing your changes.
As far as doing this again in the future or "what to do differently next time", as @Aidan says one way is to package changes in an extension, which allows management of changes to the db schema and data. Another way is to simply track those changes in whatever way you prefer so that you can replicate them in production. So script it, take notes, whatever it is... yes that's sort of dumb, but there you go. And as @Parvez Saleh says you can turn on logging as well if that helps with this (gives you a copy of every table, adding the log_ prefix in the name and a few new fields in each including a timestamp).
In general here the approach is always that production is the master copy and that anything done in dev needs to them be merged into prod, not the other way around. That's what works best in my experience, at least.
As for the current situation:
As you said everything in the file system shouldn't be too bad. Hopefully you have some sort of revisioning (git?) and you can simply deal with the changes that way. But watch that you don't override some things on prod like user uploads and the main settings files, etc. In Drupal for example these are usually in sites/default but it depends how you're set up.
As for the db this is tougher of course. If you have logging turned on (as above) this helps somewhat. I'm going to assume you have a copy of the database from before you started the changes (i.e. from when you set up the dev site). I would probably start by creating a new database and loading the original data in there. Then you can progressively try exports from both using the same queries in both and diff those export files to start building up a record of the changes. If nothing else going through this should help to remind you / build up a list of what changes were made, even if doesn't give you exact db update queries that you can simply apply.
Once you know what has changed in the db you have a few ways to deploy this to prod. In many cases it may be smarter to simply recreate the steps there, i.e. go through the admin pages, for example re-adding your new custom fields. I would do this in many cases if the changes won't take very long. If something will take a long time, there are some bulk update tools available, depending on what you're doing, and there's also the API. And of course you can always run queries on the db directly, however this is the most error prone and requires the most understanding of Civi's data structure.
