提交计算机专用配置文件

Question

我开发的一个常见场景是代码库将有几个配置文件需要特定于机器的设置.这些文件将被检入Git,其他开发人员将不小心将它们重新检入并打破其他人的配置.

一个简单的解决方案就是不将它们检入Git,甚至为它们另外添加.gitignore条目.但是,我发现在文件中有一些合理的默认值更加优雅,开发人员可以根据自己的需要进行修改.

有没有一种优雅的方式让Git很好地使用这些文件？我希望能够修改特定于机器的配置文件,然后能够在不检查该文件的情况下运行"git commit -a".

Answer 1

让您的程序读取其设置的一对配置文件.首先,它应该读取config.defaults将包含在存储库中的文件.然后,它应该读取config.local应该列出的文件.gitignore

通过这种安排,新设置将显示在默认文件中,并在更新后立即生效.只有在被覆盖的情况下,它们才会因特定系统而异.

作为对此的一种变体,您可以只使用config版本控制中提供的常规文件,并让它执行类似于include config.local引入机器特定值的操作.这在您的代码中引入了更通用的机制(与策略相对),从而实现了更复杂的配置(如果您的应用程序需要这样).在许多大型开源软件中看到的流行扩展是从include conf.d目录中的所有文件读取配置.

另请参阅我对类似问题的回答.

Answer 2

你可以试试git update-index --skip-worktree filename.这将告诉git假装文件名的本地更改不存在,因此git commit -a将忽略它.它还具有抵抗的附加优势git reset --hard,因此您不会意外丢失本地更改.此外,如果文件在上游更改,则自动合并将正常失败(除非工作目录副本与索引副本匹配,在这种情况下,它将自动更新).缺点是必须在所有涉及的机器上运行命令,并且很难自动执行此操作.另请参阅git update-index --assume-unchanged这个想法的略有不同的版本.两者的详细信息都可以找到git help update-index.

Answer 3

另一种方法是在另一个专用分支中维护对公共配置文件的本地更改.我为一些需要多次本地更改的项目执行此操作.这种技术可能并不适用于所有情况,但在某些情况下它适用于我.

首先,我基于主分支创建一个新的分支(在这种特殊情况下,我使用的是git-svn,所以我需要从master提交,但这在这里并不是非常重要):

git checkout -b work master

现在根据需要修改配置文件并提交.我通常会在提交消息中添加一些与众不同的内容,例如"NOCOMMIT"或"PRIVATE"(稍后会有用).此时,您可以使用自己的配置文件在私有分支上工作.

如果您想将工作推回到上游,请从work分支机构中选择每个更改到主服务器.我有一个脚本来帮助做到这一点,看起来像这样:

#!/bin/sh

BRANCH=`git branch | grep ^\\* | cut -d' ' -f2`
if [ $BRANCH != "master" ]; then
  echo "$0: Current branch is not master"
  exit 1
fi

git log --pretty=oneline work...master | grep -v NOCOMMIT: | cut -d' ' -f1 | tac | xargs -l git cherry-pick

这首先检查以确保我在master分支(健全性检查).然后,它列出每个提交work,过滤掉提及NOCOMMIT关键字的那些,反转顺序,最后挑选每个提交(现在从最早的第一个)到master.

最后,在推送master上游的更改后,我切换回work并重新绑定:

git checkout work
git rebase master

Git将重新应用work分支中的每个提交,有效地跳过已经应用master的樱桃选择中的一个.你应该留下的只是NOCOMMIT本地提交.

这种技术使推送过程更耗时,但它解决了我的问题所以我想我会分享.

Answer 4

一种可能性是在.gitignore中包含实际文件,但检查具有不同扩展名的默认配置.Rails应用程序的典型示例是config/database.yml文件.我们将检入config/database.yml.sample,每个开发人员创建自己的config/database.yml,它已经是.gitignored.