by Ken Task.
moodledata is unique to each implementation of Moodle ... be it production or dev.
Git should deal only with code. (while you could setup a github and your moodledata could be included in a git clone I wouldn't - dynamic nature of cache/localcache/muc etc. Think it would have potential to confuse your efforts to clone again and test upgrades.
While Emma is right ... one could copy moodledata to the dev implementation, think I'd setup an rsync script (production moodledata to dev moodledata) and have the rsync update (which means add new files but remove old files no longer on production in filedir on the dev moodledata).
Why? Once having tested an upgrade on dev, then replicating actions/commands, etc. on production, dev sites have a tendency to languish. Production server is used therefore database has grown, files uploaded to moodle have changed, students come and gone, couses added and removed. So before doing the next major upgrade, I'd replicate the production server to dev site again.
Git will handle the update to code. There is an experimental utility now in (3.2 and 3.3) for 'Database Migration'. Have tried it and it did work. That would have to create a new database ... let's call it moodledev2017 ... if you name it with a year then just by looking at the DB name one can tell when dev was last migrated and how current dev was when first created. This then allows you to skip the conversion of the FQDN ... production.yoursite.net to dev.yoursite.net - thus being able to get a dev site setup much more quickly to test the upgrade.
Have a 'customer' that contacts me about once every 2 years - they are upgrading. They have a Quality Assurance mind set. They spend much of their QA $'s just getting the QA servers up to par ... before they can begin on testing an upgrade because they insist on keeping the QA as it was rather than cloning what they have as production again before upgrading. Database requirements now much larger than when dev was first setup. And because they setup servers with different partitioning, work-arounds exist on production that don't exist on production .... like a partition for /var/mysql/ where the databases live.
Bottom line ... make the dev a clone ... no work-arounds need come into play on upgrading production. The idea is to make your admin life easier ... as close to 'no-brainer' as possible.
My 2 'sense' of course ... nope, spelled it right! ;)
'spirit of sharing', Ken