我们在一个3人正在处理的项目中有几个配置文件。但是，这些配置文件包含几行，这些行对我们每个人都不相同，因此不应该被提交更改或覆盖。然而，Git不会让我们从其他人那里获得更改，除非我们提交那些配置文件的更改，这意味着它会再次更改其他成员的配置。让git免于需要提交更改
作为Git的新手，似乎我们需要创建分支并合并它们，每次提交以更新代码 - 或使用.gitignore。处理这种情况的正确方法是什么？我们都需要不断访问其他成员所做的更改。
跟踪示例配置文件通常是一个好方法。然后你可以有一个未追踪的本地副本。您可以使用githooks来帮助您应用这些差异。您可以将合并后和结账（甚至是提交后）复制到未跟踪的跟踪中，并可能应用更改以创建自定义版本。你最后一步怎么做取决于你 - 这是一个脚本。几个电话sed -i可能会这样做。
另一种可能性，如果你能够使用两个配置文件，或者配置文件具有某种“包含”指令，那么就有一个跟踪，一个未跟踪。
不检入配置文件。
如果需要你可以有一个config.example，你们每个人都复制到未跟踪的配置文件 - 这是大多数项目如何处理这个。
我一直在发现在应用程序中使用合理的默认值以及版本控制忽略的可选配置文件的价值。一个示例配置文件可能会被签入，但使用不同的名称;通常是“config.example.yml”（或任何扩展名对你有意义）。
你也可以使用被称为“rebase --onto”的严重git-fu，如outlined here。
正如我理解这种方法，你有自己的配置更改在您自己的分支单一提交。在你自己的分支上工作。每隔一段时间，您都会跳过以上的分支您的配置提交，然后将其重新安装到主设备上。必要时重复。
一个很好的图表是Scott Chacon即将发布的Pro Git一书。
我认为这是Git最好能找出一次的东西之一。使用git config --global alias.lop 'rebase --onto etc. etc.'，这样你就可以输入例如。 git lop在未来。
我敢肯定，我建议对以下技术，但是......
您可以使用筛选器驱动程序来设置适当的配置文件为每个开发人员。检入文件可能包含一个通用值，并且每个开发人员都会有一个可以为其更改的涂抹规则。
例如，如果一个名为“配置文件”要在每个开发人员的基础修改该文件在该行的样子：
config: default
然后，开发者必须在这个当地。混帐/信息/属性：
config-file filter=modify-config
和的.git /配置是这样的：
[filter "modify-config"]
smudge = sed -e 's/^config:.*/config: developers value/'
clean = sed -e '/^config/s/.*/config: default/'