1

所以我正在寻找一种方法来处理 git projet 中的配置文件。我阅读了一些关于该主题的文章，但所有文章都建议使用第二个本地文件。这对我来说感觉不对。

所以我弄乱了一些 git 命令来寻找另一种方式来实现事情。

我发现这可能的一种方法可能是这样的：

文件

该示例的配置是key : value文件中的一个简单列表。

local状态是模板的最新拉取版本：

1 : 1
2 : 2
3 : 3

remote状态是存储库上的版本：

1 : 1
a : 2
3 : 3
4 : 4

在这个文件中，我有一个新字段：4和一个修改过的字段a。

最后，working状态是应用程序使用的配置文件。local它是使用用于运行应用程序的秘密值修改的文件的副本。此版本不应推送到存储库。

1 : secret1
2 : secret2
3 : secret3

流动

这是我想到的工作流程：

开pull/ checkout：

  • 将文件备份working到单独的文件中，以防止被重写；
  • 对local和进行合并remote以获取最后一个配置模板；
  • 有点合并local和saved_working。

只要不覆盖现有字段值，最后一次合并应该为用户提供要添加的新字段的显示。

这种操作的一个例子可能是：

第一次合并：

-    2 : 2
+    a : 2
+    4 : 4

第二次合并：

1 : secret1
-    2 : secret2
+    a : 2
3 : secret3
+    4 : 4

现在，在能够再次使用该应用程序之前，我们清楚地看到了变化的线条。

你怎么看 ？

4

2 回答 2

1

我认为一个应用程序应该能够读取很多配置文件，并且应该只在存储库中存储一个默认配置文件；例如：

  1. 阅读 /path/to/the/app/default.conf
  2. 读取系统范围的 /etc/application.conf
  3. 读取用户配置（即：~/.config/application.conf），如果它与应用程序在同一目录中，则使用.gitignore

一些项目（例如带有Vault的ansible）存储配置文件的加密版本，这也可能是一种解决方案。

它适用于您的设置吗？

另一个建议是一个单独的分支，您可以根据自己的喜好挑选代码或配置。

编辑：关于樱桃采摘的精确度。

这只是一个建议，就像你对合并的艰难，除了你选择你想从“远程”获得哪些提交。

在您的机器上，在local分支中工作：

  1. git fetch
  2. 或者你想要的git merge master提交git cherry-pick

没有什么开创性的，我不确定您是否希望该操作是自动化的或手动的。

于 2015-07-21T06:30:49.647 回答
0

我建议您仔细考虑为什么需要将配置文件存储在 repo 中？如果这是一些默认选项集，那么它可能应该集成到项目中（可能编译成二进制文件；IDK 你的项目是什么）。如果这是一个示例选项集，那么您不需要在工作树中使用它，所以在拉动时忽略它。无论如何，当配置文件丢失时，软件不应该无法使用，它应该有一些默认值，因此你不需要将你的工作配置与 repo 的版本合并。

我曾经将我的配置保存在 repo 中，但后来改变了主意并删除了所有这些提交。Config 是指用户偏好的可变状态；代码仓库用于存储代码的历史。混合这两个主题对我来说似乎是不好的做法。

更新

如果您不想支持将配置从旧版本升级到最新版本，那么我只能想象一种方法：

  • 在 repo 中存储配置模板
  • 向 repo 添加一个工具，将实际配置从以前的版本升级到最近的版本（它可以是一个小程序，甚至更好的脚本）
  • 将此工具设置为在拉后事件启动。

因此，每次开发人员从远程仓库拉取时，配置工具也会更新然后启动。修订版中提交的工具将实际配置文件从以前的版本升级到此修订版中引入的最新版本。显然纯文本工具在这里更可取（用于跟踪更改），但二进制也可以。

于 2015-07-21T09:04:14.637 回答