A Drupal 7 database contains various structural configuration. Some of these are:
- Entity bundles, e.g. node types or taxonomy vocabularies.
- Field bases: These are definitions of fields that apply across bundles and entity types, wherever the same field is used.
- Field instances: These describe how a field is used for a specific entity bundle.
- Field display configuration per entity bundle and view mode. This gets even more with Display suite.
- General global key/value settings, stored in the variable table, which can be accessed with variable_get() and variable_set(). These are exported to features with strongarm.
Unfortunately, this entire system is a bit "dirty": Some of the structural configuration for fields and entity bundles is stored in the variable system, and not together with the field or entity type.
Therefore, whenever you export an entity bundle (e.g. node type) with features, you will also see some strongarm stuff. This is annoying and messy, but it is not avoidable.
I would recommend to maintain
- One feature containing all field bases.
- One feature per node type, with all field instances and field display configuration for this node type. This will also contain a lot of strongarm stuff.
- Another feature for general strongarm settings, that are not related to anything else.
- And more.
As far as I remember,
drush features-export myfeature node:mytype already adds all the field instances and strongarm stuff for this node type.
Ideally you also have a naming pattern such as
mysite_ft_* for all features, and
mysite_ft_ct_* for all content type features. Also organize your sites/all/modules into
So in conclusion: You don't have a choice to pick either field base or field instance or strongarm. Instead, you usually want to export everything that you want to sync between your local environment and the dev, staging or live environments. The only choice is which of those things should live in the same feature, and which parts should live in different features.