我们在一个 3 个人正在处理的项目中有几个配置文件。但是，这些配置文件包含对我们每个人都不同的几行，因此不应被提交更改或覆盖。然而 Git 不会让我们从其他人那里拉取更改，除非我们提交这些配置文件更改，这意味着它会再次更改其他成员的配置。
作为 Git 新手，我们似乎要么需要创建分支并在每次提交时合并它们以更新我们的代码 - 要么使用 .gitignore。处理这种情况的正确方法是什么？我们都需要不断访问其他成员所做的更改。
【问题讨论】：
标签： git
不要签入配置文件。
如果需要，您可以拥有一个 config.example，每个人都将其复制到一个未跟踪的配置文件中 - 这是大多数项目处理此问题的方式。
【讨论】：
我发现在应用程序中使用合理的默认值以及版本控制忽略的可选配置文件的价值。可以签入示例配置文件，但名称不同；通常是“config.example.yml”（或任何对您有意义的扩展名）。
【讨论】：
跟踪示例配置文件通常是一种好方法。然后，您可以获得未跟踪的本地副本。您可以使用githooks 来帮助您应用差异。您可以让合并后和签出后（甚至可能是提交后）将跟踪的内容重新复制到未跟踪的内容，并可能应用更改来创建您的自定义版本。最后一点如何做取决于你——它是一个脚本。不过，打几个电话 sed -i 可能就可以了。
如果您能够使用两个配置文件，或者配置文件具有某种“包含”指令，则另一种可能性是跟踪一个，一个不跟踪。
【讨论】：
我很确定我不建议使用以下技术，但是...
您可以使用过滤器驱动程序为每个开发人员适当地设置配置文件。签入的文件可以包含一个通用值，每个开发人员都会有一个涂抹规则来为他们更改它。
例如，如果您要在每个开发人员的基础上修改名为“config-file”的文件中的行如下所示：
配置：默认然后开发人员会在他们的本地 .git/info/attributes 中有这个：
配置文件过滤器=修改配置在 .git/config 中类似这样的东西：
[过滤“修改配置”] smudge = sed -e 's/^config:.*/config: 开发者价值/' clean = sed -e '/^config/s/.*/config: default/'【讨论】：
您也可以使用称为“rebase --onto”的严肃 git-fu，如 outlined here。
据我了解，您可以在自己的分支上的一次提交中进行自己的配置更改。在自己的分支上工作。每隔一段时间，您就会从配置提交的 above 中删除分支，然后将其重新缝合到 master 上。根据需要重复。
Scott Chacon 即将出版的Pro Git 书中有一个很好的图表。
我认为这是 Git 最好弄清楚一次的事情之一。使用git config --global alias.lop 'rebase --onto etc. etc.' 这样您就可以输入例如。 git lop 未来。
【讨论】：