一种方法是以只有您本地才能看到的方式修改配置文件。
但在某种程度上，仍然是无形的其他用户的回购。
如果这些修改定义得很好（并且不是在your.config.file中到处都是），那么您可以考虑使用content filter driver，以便在 checkout 时为该配置文件生成正确的内容：

• 在.gitattributes declaration：

your.config.file filter=filterconfig

(edit或者在本地存储库的根文件夹中创建一个.gitattributes文件，并在其中添加上面的行。它不会对其他用户产生任何影响）。

（图片来自“自定义Git - Git属性，”来自“Pro Git book“）

cd /path/to/your/local/cloned/repo
git config filter.filterconfig.smudge 'update_config'
git config filter.filterconfig.clean 'restore_config'

update_config和restore_config脚本可以在本地$PATH上的任何地方（即使你在Windows上，它们也在bash中，因为它们将由mingw git bash执行）。
update_config脚本将：

• 创建配置文件的初始副本，
• 将其修改注入到配置文件中。

这样，触发工作树更新的git pull将自动重新生成包含所需本地修改的配置文件内容。
每当git调用restore_config脚本时，它就会恢复文件的副本（例如，它会被git status或git diff触发）：

cat saved_copy

这样，在git看来，config文件 * 看起来 * 永远不会改变。

我一直在使用的一个策略，就是使用两个分支：一个分支是公共的，另一个分支永远不会离开您的计算机，并且包含您的配置更改。
当你进行开发时，你 checkout 了私有分支，但是你并没有提交它。一旦你对你的修改感到满意，你就把它们藏起来， checkout 公共分支，执行一个git stash pop，然后提交结果。之后，你返回私有分支并合并你的新提交。产生的历史看起来像这样：

*   (HEAD->private) merge
|\
| * (public) commit 3
* | merge
|\|
| * commit 2
* | a change in your local configuration
* | merge
|\|
| * commit 1
* | some private configuration changes
 \|
  * some base commit

现在，如果你绘制public分支的历史记录，你会得到：

* (public) commit 3
* commit 2
* commit 1
* some base commit

正如你所看到的，没有一个公共提交依赖于你对配置的本地修改，这使得公共历史记录中没有你的配置修改。然而，你的配置修改是完全受版本控制的，所以你可以回到你的任何合并提交，并知道你将能够进行构建。
当然，这样做的代价是不断改变分支的麻烦。所以我会尽可能避免这样的构造，但在某些情况下它会很有帮助。

看起来像是一份工作--没有变化。

git update-index --assume-unchanged <file>

这将阻止您的更改被暂存和提交。

git update-index --no-assume-unchanged <file>

恢复正常。