I like to take an approach where content is organized into 'packages' with the content root, and packages can be scheduled into the production build (in order) via some kind of manifest.
The simplest implementation of this technique is a flat-file one, where you have an asset directory which subdirectories for each package. Each package subdirectory contains assets, possibly in a fixed tree form (such as all the models in a 'model' folder).
The manifest simply contains an ordered list of packages to apply to a build -- packages applied later override those applied earlier. The manifest for dev builds includes the packages for developer-only stuff, and the manifest for live builds doesn't.
Obviously you can scale this out to an arbitrary complexity, supporting things like efficient fallbacks for missing resources if you forget to schedule in a package, or emitting warnings, et cetera. The system lends itself well a local 'override' directory, too, allowing for quick asset iteration.
This approach is orthogonal to the SCM package used, so you don't necessarily need a branch per package or anything like that.