最佳实践 - Git + 构建自动化 - 将配置分开 [英] Best practice - Git + Build automation - Keeping configs separate

问题描述

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

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

必须:

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

提前致谢.

解决方案

即所谓的":

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

使用这种方法，您不需要子模块，但是您可以根据您的环境生成所需数量的配置文件，例如您的分支:
有点像在更新后钩子中查找 Git 分支名称"，你的涂抹脚本可以找出它在哪个分支当前正在执行:

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

Searching for the best approach to keep my config files separate, yet not introduce extra steps for new developers setting up their environments.

I am guessing a submodule would suffice to do the job, but then how would I switch configs seamlessly depending on the task at hand, aka pull in DEV config regularly, pull PROD branch of config repo during build?

Needs to be:

• Easy and painless for new devs.
• PROD config files should only be accessible to select users + build user.

Thank you in advance.

解决方案

That is called content filter driver, and it allows you to declare, in a .gitattributes file (and only for your config files type) a smudge script which will automatically on checkout:

• combine a config file template file (config.tpl)
• with the right config file value (config.dev, config.prod, ...)
• in order to produced a non-versioned config file (private file)

See "Customizing Git - Git Attributes":

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

With that approach, you don't need submodules, but you can generate as many config file you need depending on your environment, like for instance your branch:
A bit like in "Find Git branch name in post-update hook", your smudge script can find out in which branch it is currently executing with:

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

这篇关于最佳实践 - Git + 构建自动化 - 将配置分开的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！