I do this all the time:
drush up feature_name
git commit -a
this gives you a nice diff of the config in production v's code. drush fd feature_name
sometimes i really need to make a fix in production (or its so trivial the overhead of a release would be just silly), make the change on production, then grab fresh db dump, stick it on dev box and run "drush up". today i did this to remove a link from a field in a view.
The code defines the default configuration.
If the user changes the config using the UI, the change gets written to the database. At the same time, a little telltale light (or something) tends to appear in the UI display, to alert the admin that something's been changed on the site, but not in the code.
Your developer can then come along and pull a report that lists any configuration that's been changed in the UI but not migrated to the code. Pressing a button spits out a code-based representation of that configuration. The developer finds the right file, pastes in the config change, checks into Git or SVN. Now the config is once again captured in code, and ready to be deployed in a consistent manner.
I'm not sure if the Drupal 8 team is using this pattern or something different. Still trying to catch up with this stuff.