Git 自定义合并处理配置文件

Posted 2023-04-19

【中文标题】Git 自定义合并处理配置文件

【英文标题】：Git custom merge to handle configuration files

【发布时间】：2015-10-10 11:19:00

【问题描述】：

所以我正在寻找一种方法来处理 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

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

你怎么看？

【参考方案1】：

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

读取/path/to/the/app/default.conf 读取系统范围的 /etc/application.conf 读取用户配置（即：~/.config/application.conf），如果和应用在同一目录下，使用.gitignore

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

它适用于您的设置吗？

另一个建议是一个单独的分支，您可以在其中 cherry-pick 代码或配置，具体取决于您的偏好。

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

这只是一个建议，就像你在合并时遇到的难题，只是你选择要从“远程”获取哪些提交。

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

git fetch git merge master 或 git cherry-pick 你想要的提交

没有什么突破性的东西，我不确定您是否希望操作是自动的还是手动的。

【讨论】：

我同意你关于多配置文件部分的看法，但我真的想要一种没有的方法......你能解释一下关于樱桃挑选部分的更多信息吗？ :)

【参考方案2】：

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

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

更新

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

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

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

【讨论】：

这里的情况是，当多人在不同环境的同一个项目上工作时，他们需要在某个地方指定它。所以配置文件很有用。我们从配置文件中唯一需要的是模板，所以我们想要共享模板而不是其中的实际配置

@Nobe4 是的，正如我所想。因此，您希望在开发人员之间共享一个配置框架。我建议将其集成到您的项目中时就是这种情况。在大多数情况下，更改配置模板涉及代码更改：对话框、文件读写、使用新选项等。所以配置模板成为项目代码的一个组成部分，因为没有新代码新模板将无用，没有新模板新代码将失败。在这种情况下，模板应该与其他代码库一起拉取，并以特定方式在内部加载，这与加载通常的自定义配置不同。

没错，但是我们集成一个配置，它必须适合每个人的配置。所以有些值不需要在不同的环境中改变......

@Nobe4 我不明白为什么 new 代码应该无法处理旧配置。我在上面的答案中添加了另一个想法