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

Question

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

现在，在能够再次使用该应用程序之前，我们清楚地看到要改变的行。

您怎么看？

Answer 1

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

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

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

它适用于您的设置吗？

另一个建议是根据您的偏好cherry-pick代码或配置的单独分支。

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

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

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

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

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

Answer 2

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

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

<强> UPD

如果您不想支持将旧版本的配置升级到最近的版本，我只能想象一种方式：

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

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