Git rebase and semi-tracked per-developer config files

This is my first SO question and I'm new-ish to Git as well.

Background: I am supposed to be the version control guru for Git in my group of about 8 developers. As I don't have a lot of Git experience, this is exciting. I decided we need a shared repository that would be the authoritative master for 开发者_如何学JAVAthe production code and the main meeting-point for the development code. As we work for a corporation, we really do need to show an authoritive source for the production code at least.

I have instructed the developers to pull-rebase when pulling from the shared repository, then push the commits that they want to share. We have been running into problems with a particular type of file.

One of these files, which I currently assume is typical of the problem, is called web.config. We want a version-controlled master web.config for devs to clone, but each dev may make minor edits to this file that they wish to locally save but not share.

The problem is this: how do I tell git not to consider local changes or commits to this file to be relevent for rebasing and pushing? Gitignore does not seem to solve the problem, but maybe that's because I put web.config into .gitignore too late?

In some simple situations we have stacked local changes, rebased, pushed, and popped the stack, but that doesn't seem to work all of the time. I haven't picked up the pattern quite yet.

The published documentation on pull --rebase tends to deal with simplier situations.

Or do I have the wrong idea entirely? Are we misusing Git?

Dougkiwi

The general idea behind config file is to only put under source control:

• a template of it,
• a script able to generate a proper config file based on local data (username, hostname, ip address, and so on)

The other solution would be to do this in a dev branch, along with other local devs, and add a custom merge driver to merve merge back those config file modifications.
But that more complex and generally not needed if your template file is correctly built.

Maybe you can force a conflict and add a rere configuration you don't change data. But I think it's better to have no commit with change in this change.