Drupal's Features module tends to use this pattern:

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.

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.

woops... "drush up" should be "drush fu"

On a site that is version controlled and has a QA workflow for changes, you simply disable the UI for changing those things on production, and the only way to influence them is by committing the changes exported as code and deploying.

The UI is enabled on development environment, allowing for extremely quick experimentation (possibly by non-technical folk), but you still get (most) of the benefits of changes being in code.

ETA: It's not perfect, but it's on it's way to becoming the best of both worlds. Drupal 8 is making significant progress in that direction.