For Drupal 8, see https://www.drupal.org/documentation/administer/config
The Configuration Management module enables the ability to keep track of specific configurations on a Drupal site, provides the ability to move these configurations between different environments (such as local, development, quality assurance, and production), and also move configurations between completely different sites (i.e. migrate configurations) without the use of modules with all configuration being owned by the site.
For the most part, this module provides the same functionality as a subset of the Features module. The Features module is currently the 'go-to' tool for moving configuration from environment to environment and site to site. While it does a great job doing this, "configuration management" was never really what the Features module was intended to do. The goal of the Features module was to group configurations together to satisfy a certain use-case. Instead, most people use the Features module to export configuration to code to ease deployment between environments. Many of us have experienced the shortcomings of using the Features module for configuration management and have found cases where it doesn't quite allow us to easily manage configuration. A couple of other modules have spawned off of the Features module to help with some of these shortcomings: Features Override, Features Plumber, Features Tools.
The Configuration Management module takes some concepts from the Drupal 8.x core configuration management initiative, specifically the concept of the activestore and datastore architecture. Read up on how Drupal 8.x will manage configurations to get an idea of how this module manages configuration between the activestore and datastore.
The Configuration Management module knows what configuration was changed and allows users to either activate a configuration that was changed in the datastore, or write to datastore if a configuration was changed in the activestore. If you enable the Diff module, you can then see a comparison between the contents of the activestore versus the datastore.
The granularity level goes down to each specific config, rather than an entire group of them (as the Features module does). This makes it easier to activate or write to file-specific configurations, without having to features-update or features-revert an entire group of configurations.
