【问题标题】:Git best practice for config files etc配置文件等的 Git 最佳实践
【发布时间】:2012-03-09 17:12:06
【问题描述】:

我对 git 的所有东西还是新手,想知道关于配置文件的最佳实践是什么。我的本地开发服务器需要与我的实时服务器不同的配置值,那么如何阻止它推送/拉取这些文件?

【问题讨论】:

  • 将此文件包含到 .gitignore

标签: git github config


【解决方案1】:

我总是使用另一个名称来制作默认配置文件,例如rename_to_config.ini。程序尝试读取config.ini,如果不存在则返回错误。

优点:

  • 我可以将真实的config.ini 保留在.gitignore 中,不会与git add . 一起添加。
  • 您可以确认用户必须考虑配置文件,以防它具有数据库信息等必填字段。

缺点:

  • 用户无法立即使用默认配置运行程序。
  • 可能不是一种非常标准的做事方式。

【讨论】:

    【解决方案2】:

    有多种选择:

    1。提交默认配置文件,但允许本地配置文件

    将文件 default.conf 添加到您的 Git 存储库。

    您的应用首先查找app.conf,但如果不存在,则使用default.conf

    想要非默认配置的用户可以将default.conf复制到app.conf,然后进行编辑。

    用户不应将app.conf 提交到存储库中,因为不同的用户可能需要该文件中的不同设置。 (所以你应该把app.conf放到你的.gitignore中。)

    稍加改动(推荐)

    您的应用始终加载default.conf,但如果app.conf 存在,那么它将复制来自app.conf 的设置,而不是来自default.conf 的设置。

    这种转折有几个优点:

    • app.conf 只需保留与默认值的差异,使其更小更易于维护。

    • 当应用更改时,添加到default.conf 的新默认值将可供应用使用,而无需用户将它们复制到app.conf

    这个解决方案与上面 Alan W. Smith 的回答非常相似,但有一点不同:如果应用程序可以在没有 app.conf 文件存在的情况下启动,那么它将开箱即用。但是,它确实给应用的启动代码增加了一些复杂性。

    这个建议是 Linus Torvalds 在 git 或内核邮件列表中提出的几个建议之一,但我今天没能找到它。

    2。使用环境变量和/或命令行参数

    您可以使用环境变量将您的应用指向特定的配置文件。你可以这样启动你的应用:

    CONFIG_FILE=test.conf ./start-app
    

    或者:

    ./start-app --config=test.conf
    

    这意味着您可以拥有多个配置文件development.confstaging.confproduction.conf。当您启动应用程序时,您会告诉它使用哪个配置文件。

    想要尝试不同配置的开发人员可以指向他们自己的文件,例如custom.conf.

    您还可以使用环境变量或命令行参数来覆盖特定设置:

    ./start-app --config=default.conf --db-url=... --debug-level=5
    

    3。不同的分支

    您可以将默认配置保留在 master 分支中。

    为每个不同的环境分叉出不同的分支。

    每个分支都可以根据需要修改默认配置文件。

    当你的 master 分支更新时,从 master 合并到你的特定分支。

    我个人不推荐这种方法。我认为它更难维护。

    【讨论】:

    • 我真的很喜欢#1。我已经制作并使用了这种模式,效果很好。感谢您的回答 - 我希望它超越 1st =P
    【解决方案3】:

    Git 将忽略您未明确添加的文件,因此检查不同的分支只会将它们留在目录结构中的位置,因为其他文件会在它们周围发生变化。如果您将配置文件添加到存储库根目录中的 .gitignore 文件中(可能需要创建它,更多信息here),那么您仍然可以执行所有文件命令,例如

    git add .
    

    如果你愿意,不用担心。

    【讨论】:

      【解决方案4】:

      使用符号链接。

      举个例子,你有一个名为“config.ini”的配置文件。在 git repo 的工作目录中,您将执行以下操作:

      1. 创建一个名为“config-sample.ini”的配置文件版本。这是您将完成所有工作的文件。

      2. 在“config.ini”和“config-sample.ini”之间创建一个符号链接。

        ln -s config-sample.ini config.ini
        

        这让您的所有代码都指向“config.ini”,即使您确实在维护“config-sample.ini”。

      3. 更新您的 .gitignore 以防止存储“config.ini”。即添加“config.ini”行:

        echo "config.ini" >> .gitignore
        
      4. (可选,但强烈推荐)使用“config.ini export-ignore”行创建一个 .gitattributes 文件。

        echo "config.ini export-ignore" >> .gitattributes
        
      5. 做一些编码和部署......

      6. 将代码部署到生产环境后,将“config-sample.ini”文件复制到“config.ini”。您需要进行任何必要的调整以进行生产设置。您只需在第一次部署时以及任何时候更改配置文件的结构时执行此操作。

      这样做的一些好处:

      • 配置文件的结构在 repo 中维护。

      • 可以为开发和生产之间相同的任何配置选项维护合理的默认值。

      • 每当您将新版本推送到生产环境时,您的“config-sample.ini”都会更新。这使您更容易发现您需要在“config.ini”文件中进行的任何更改。

      • 您永远不会覆盖“config.ini”的生产版本。 (带有 .gitattributes 文件的可选步骤 4 增加了一个额外的保证,即即使您不小心将“config.ini”文件添加到存储库中,您也永远不会导出它。)

      (这在 Mac 和 Linux 上非常适合我。我猜在 Windows 上可能有相应的解决方案,但其他人必须对此发表评论。)

      【讨论】:

        【解决方案5】:

        最好的方法是创建一个名为“.gitignore”的文件并插入您想要忽略的文件/文件夹。

        这样你可以让 git add * 每次

        【讨论】:

          猜你喜欢
          • 1970-01-01
          • 2013-02-21
          • 1970-01-01
          • 2017-09-06
          • 1970-01-01
          • 2023-03-06
          • 2023-04-08
          • 2016-06-05
          • 1970-01-01
          相关资源
          最近更新 更多