最佳实践 - Git + 构建自动化 - 将配置分开

Posted 2023-03-22

【中文标题】最佳实践 - Git + 构建自动化 - 将配置分开

【英文标题】：Best practice - Git + Build automation - Keeping configs separate

【发布时间】：2014-01-16 07:23:00

【问题描述】：

寻找将我的配置文件分开的最佳方法，但不会为新开发人员设置他们的环境引入额外的步骤。

我猜一个子模块就足以完成这项工作，但是我将如何根据手头的任务无缝切换配置，也就是定期拉入 DEV 配置，在构建期间拉出配置 repo 的 PROD 分支？

需要：

对于新开发人员来说简单而轻松。 PROD 配置文件应该只能由选择用户 + 构建用户访问。

提前谢谢你。

【问题讨论】：

我刚刚编辑了答案以添加一种方法来检测脚本正在执行自身的分支。

【参考方案1】：

这称为 content filter driver，它允许您在 .gitattributes 文件（并且仅适用于您的配置文件类型）中声明一个 smudge 脚本，它将在结帐时自动：

组合一个配置文件模板文件(config.tpl) 具有正确的配置文件值（config.dev、config.prod、...） 为了生成一个非版本化的配置文件（私有文件）

见“Customizing Git - Git Attributes”：

echo '*.cfg.tpl filter=config' >> .gitattributes
git config --global filter.config.smudge yourScript

使用这种方法，您不需要子模块，但您可以根据您的环境生成尽可能多的配置文件，例如您的分支： 有点像“Find Git branch name in post-update hook”，你的涂抹脚本可以找出它当前在哪个分支中执行：

#!/bin/sh
branch=$(git rev-parse --symbolic --abbrev-ref HEAD)

【讨论】：

谢谢。尽管我最终选择了单独存储配置并将我的设置木偶化的路线，但这仍然是很好的信息，我以前从未知道此功能。

echo '*.cfg.tpl config' 是否不需要参数名称filter=，即改为echo '*.cfg.tpl filter=config' >> .gitattributes。或者如果.giattributes 中没有提供参数名称，那么filter 是Git 在配置中查找的默认参数吗？

@ToJo 好点，谢谢。我一定是在 6 多年前错过了它。我已经相应地编辑了答案。