Git: "Sub-project" differentiation in a Stage, Live, Development web environment

I have a complex web project template where files can be divided into three categories. Firstly, settings related files that should be unique on each server, is not updated frequently, but would be nice to have it in version control. Secondly, development files which is the actual files coded by developers and is unique per project and is the main files to be version controlled. And finally, user generated content which would be mostly test data on Stage and Development environment, but proper data on a Live server, and ideally should also be version controlled.

In the root folder of every project is a settings file which is part of the first group, then there are three folders containing development files, and finally a folder that contains images for the website, as well as user generated files.

What I've tried:

I can't use the entire folder, as I would then have the same user generated content on local live and stage, and would have to readjust the settings files each time I push from local to stage, and from stage to live.

I've tried using the master branch for the development files, and a separate branch for user generated content and settings files, and then just push the master from local to stage, etc. But when I do a checkout on stage, it deletes the unrelated files.

I've tried making separate branches for development, user generated content, and settings, and then after pushing to stage just merging everything into master. The problem in this case arises on the local dev server, where the commit process becomes slightly convoluted: checkout dev; add changed files; commit dev; checkout master; merge dev ugc settings. I'm also worried that some of the ugc tracked files will be lost in this case.

The big question

Can anyone suggest a new solution or anything to add to the current solutions to make them possible? Unfortunately I cannot use separate folde开发者_开发问答rs as the framework (a private one) used does not allow it.

Though it's a really terrible way of organizing things, you could use nested Git repositories with .gitignore files that ignore anything which doesn't belong in a given repository:

.git/
.gitignore   <---- ignoring everything except settings-file
your_project
  .git/
  .gitignore <---- ignoring settings-file, user content, and user-content/.git
  dev-folder-1/
  dev-folder-2/
  settings-file
  user-content/
    .git/
    .gitignore <-- ignoring everything except user content

That would effectively allow you to have 3 different 'overlapping' repositories which track different parts of the file structure.

But really, it'd be better to just find a way to reorganize your files and/or version control needs.