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