【问题标题】:What's a good strategy for an open source project to not share production settings? [closed]开源项目不共享生产设置的好策略是什么? [关闭]
【发布时间】:2012-02-02 09:02:48
【问题描述】:

我目前希望将 MVC / RavenDB 作为开源存储库发布,主要是为了让人们环顾四周,而不是作为一个完整的项目。

但是我不希望某些生产设置,例如 SMTP 服务器详细信息和连接字符串公开(但仍处于源代码控制之下)。

我正在寻找有关如何构建公共和私有存储库的建议,以便我可以轻松地处理项目并进行相当轻松的部署。

干杯

【问题讨论】:

  • 不会有这个工作的私人分支吗?那么您可以使用拉取请求更新开放版本吗?

标签: version-control mercurial open-source


【解决方案1】:

在与您类似的情况下,我需要公开发布部件并隐藏导入数据,我通常非常简单地保留一个仅用于生产的分支。

在您的情况下,您可以将发布所有内容的 dev 分支设为开源,克隆它并从其他人那里获得一些贡献。然后在不同的地方建立一个生产分支。 (heroku..)

【讨论】:

    【解决方案2】:

    您通常不会将这些文件置于版本控制之下。例如,在公司内部,您可以将 模板 置于版本控制之下,并要求开发人员将其复制到位并根据需要进行更新。就像一个带有

    config.ini.template文件
    [smtp]
    host = smtp.company.com
    user = USERNAME # update this
    pass = PASSWORD # and this
    

    很明显,开发人员在将凭据重命名为config.ini 时需要更新凭据。然后应该将config.ini 文件从版本控制中排除。

    对于一个开源项目,我可能不会将任何模板置于版本控制之下。我仍然会对其进行配置,以便将 config.ini 文件排除在版本控制之外,这样我就可以在我的工作副本中拥有自己的 config.ini 文件,而不会意外提交。

    我发现上述系统比将真正的配置文件置于版本控制之下要容易得多。即使我可以将它放在某种私有分支中,也需要我不断地与该分支合并,并且我必须小心不要意外地将配置文件推送到另一个存储库。

    【讨论】:

    • +1 用于 VC 下的模板配置
    猜你喜欢
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 2011-08-26
    • 1970-01-01
    相关资源
    最近更新 更多