Git 自定义合并处理配置文件
Git custom merge to handle configuration files
所以我正在寻找一种方法来处理 git 项目中的配置文件。我阅读了一些有关该主题的文章，但所有文章都建议使用第二个仅限本地的文件。这对我来说并不合适。
所以我弄乱了一些 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
现在，在能够再次使用该应用程序之前，我们清楚地看到要更改的行。
你怎么看？
我认为一个应用程序应该能够读取很多配置文件，并且应该只在存储库中存储一个默认的配置文件；例如：
- 阅读/path/to/the/app/default.conf
- 读取系统范围的 /etc/application.conf
- 读取用户配置（即：~/.config/application.conf），如果它与应用程序在同一目录中，请使用.gitignore
一些项目（如ansible with Vault）存储配置文件的加密版本，这也可能是一个解决方案。
它适用于您的设置吗？
另一个建议是一个单独的分支，您可以在其中 cherry-pick 代码或配置，具体取决于您的喜好。
编辑： 樱桃采摘的精度。
这只是一个建议，就像您在合并方面遇到困难一样，只是您选择要从 "remote".
中获得哪些提交
在您的机器上，在 local 分支中工作：
git fetchgit merge master 或 git cherry-pick 您想要的提交
没什么突破性的，我不确定你希望操作是自动的还是手动的。
我建议你仔细想想为什么你需要在 repo 中存储配置文件？如果这是一些默认选项集，那么它可能应该集成到项目中（可能编译成二进制文件；IDK 你的项目是什么）。如果这是一个示例选项集，那么您不需要在您的工作树中使用它，所以在拉动时忽略它。无论如何，当配置文件丢失时，软件不应该无法使用，它应该有一些默认值，因此您不需要将您的工作配置与 repo 的版本合并。
我曾经将我的配置保存在 repo 中，但后来改变了主意并删除了所有这些提交。 Config 是指用户偏好的可变状态； code repo 用于存储代码的历史记录。混合这两个科目对我来说似乎是不好的做法。
upd
如果您不想支持将配置从旧版本升级到最新版本，我只能想到一种方法：
- 在 repo 中存储配置模板
- 向 repo 添加一个工具，将实际配置从以前的版本升级到最近的版本（它可以是一个小程序，甚至更好的脚本）
- 将此工具设置为在 post-pull 事件上启动。
所以每次开发人员从远程仓库中拉取时，配置工具也会更新然后启动。在修订版中提交的工具将实际配置文件从之前的版本完全升级到该修订版中引入的最新版本。显然纯文本工具在这里更可取（用于跟踪更改），但二进制也可以。
所以我正在寻找一种方法来处理 git 项目中的配置文件。我阅读了一些有关该主题的文章，但所有文章都建议使用第二个仅限本地的文件。这对我来说并不合适。
所以我弄乱了一些 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
现在，在能够再次使用该应用程序之前，我们清楚地看到要更改的行。
你怎么看？
我认为一个应用程序应该能够读取很多配置文件，并且应该只在存储库中存储一个默认的配置文件；例如：
- 阅读/path/to/the/app/default.conf
- 读取系统范围的 /etc/application.conf
- 读取用户配置（即：~/.config/application.conf），如果它与应用程序在同一目录中，请使用.gitignore
一些项目（如ansible with Vault）存储配置文件的加密版本，这也可能是一个解决方案。
它适用于您的设置吗？
另一个建议是一个单独的分支，您可以在其中 cherry-pick 代码或配置，具体取决于您的喜好。
编辑： 樱桃采摘的精度。
这只是一个建议，就像您在合并方面遇到困难一样，只是您选择要从 "remote".
中获得哪些提交在您的机器上，在 local 分支中工作：
git fetchgit merge master或git cherry-pick您想要的提交
没什么突破性的，我不确定你希望操作是自动的还是手动的。
我建议你仔细想想为什么你需要在 repo 中存储配置文件？如果这是一些默认选项集，那么它可能应该集成到项目中（可能编译成二进制文件；IDK 你的项目是什么）。如果这是一个示例选项集，那么您不需要在您的工作树中使用它，所以在拉动时忽略它。无论如何，当配置文件丢失时，软件不应该无法使用，它应该有一些默认值，因此您不需要将您的工作配置与 repo 的版本合并。
我曾经将我的配置保存在 repo 中，但后来改变了主意并删除了所有这些提交。 Config 是指用户偏好的可变状态； code repo 用于存储代码的历史记录。混合这两个科目对我来说似乎是不好的做法。
upd
如果您不想支持将配置从旧版本升级到最新版本，我只能想到一种方法：
- 在 repo 中存储配置模板
- 向 repo 添加一个工具，将实际配置从以前的版本升级到最近的版本（它可以是一个小程序，甚至更好的脚本）
- 将此工具设置为在 post-pull 事件上启动。
所以每次开发人员从远程仓库中拉取时，配置工具也会更新然后启动。在修订版中提交的工具将实际配置文件从之前的版本完全升级到该修订版中引入的最新版本。显然纯文本工具在这里更可取（用于跟踪更改），但二进制也可以。