跟踪文件，但将其从git包中排除

我的工作流程有点复杂。我有两个空的网络。我在这两个网络上都开发剧本，所以我有两个由git管理的独立ansible存储库。同时，大多数剧本可以在这两个地方使用。使事情复杂化的是，这是一种单向转移。我可以从网络A传输到B，但不能从B传输到A

我有与一个网络相关但与另一个网络无关的信息模板文件。我设计的文件名应该是相同的（以及Jinja2模板中的变量名）。我希望能够创建一个排除文件的git捆绑包，这样当我从另一个网络的存储库上的捆绑包中提取文件时，文件不会被覆盖。因为在模板文件中包含错误的信息可能会破坏整个环境，所以我需要在Git中跟踪Jinja2模板/变量文件

---

除了使用.gitignore（因为需要跟踪文件以便在紧急情况下回滚）之外，是否有人有工作流建议或git命令可以帮助我完成此任务？

没有完全简单的方法可以做到这一点

基本上，当且仅当文件在索引中时，才在Git中跟踪该文件。索引（通常，最初）是从某个提交中填充的，因此决定是否要跟踪文件的是以前的某个提交。假设存在两组相似的提交T和U，但有一些文件不在提交U中，而在提交T中。然后：

导致文件位于索引中（并因此被跟踪），而：

导致文件不在索引中（因此未跟踪）

对于像合并这样的操作，这一点在更一般的情况下也适用：当您使用集合T中的提交时，您使用的是包含文件的提交；当您使用集合U中的提交时，您将使用缺少文件的提交。如果将任何Ti commit与任何Uj commit合并，则添加、删除或冲突对任何此类文件的影响取决于合并基提交是在集合T中还是集合U中，以及在commit Ti中对这些文件进行的与合并基提交相关的特定更改

当然，当文件移入或移出索引时，Git也会同时将它们复制到工作树中或从工作树中删除它们（通常注意不要删除未保存但宝贵的数据）。因此，这意味着工作树文件将消失并重新出现，具体取决于您是签出T提交还是U提交

同时，让我们看看捆绑包是什么，至少在抽象意义上是这样的。捆绑包的本质是，它至少包含

git-fetch

或

git-push

在

git-fetch

或

git-push

通信过程之后通过线路发送的所有数据，以最小化这些数据。（它可以包含额外的数据，这些数据将被忽略。）此最小数据由所有必须复制的对象组成，包括带注释的标记、提交、树和blob，以及引用名称及其值

要从捆绑包中排除某些文件集，则需要专门捆绑U提交，而不是任何T提交。就这一点而言，这很好：如果所有分支都是重复的，并且通过分支名称区分T提交和U提交，那么可以很容易地实现这一点。但其结果是，每次进行新的T提交时，都必须进行相应的U提交，反之亦然。实际上，你的工作量增加了一倍

通常适用于配置文件的标准建议也适用于此：永远不要提交任何配置。仅提交示例配置、默认配置或模板配置。使用某种包装器将这些示例配置转换为实际配置。（当然，如果是您自己编写的东西，比如shell脚本或Python程序等，也可以提交包装器。）您现在可以维护和控制这些示例/默认配置。克隆存储库获得样本，然后从克隆中更新-

git fetch

，然后进行合并或重新基址更新样本，但不涉及实际配置。根据包装器的智能程度和输出格式的可用性，1它甚至可以自动检测样本/默认输入已更改，并警告或失败使用指定工具（即包装器本身）的任何运行直到更新真实配置以匹配来自示例/默认/模板配置的任何所需更改

这仍然不是小事，特别是，您可能必须编写一个包装器，并指导用户如何正确运行您的特定系统。但这是你可能达到的最微不足道的目标

---

---

1在这种情况下，您的输出很可能是ansible的YAML文件。这意味着您可以在注释中隐藏各种有用的示例/默认配置信息。

Wow，我真的非常感谢您将此应用到如此正式的分析中！我的集合论有点生疏，但我明白你的解释。不幸的是，你也证实了我的怀疑和恐惧。我要么必须维护实际的配置值数据，而不在同一存储库中跟踪它，要么采取一些荒谬的措施将其从捆绑包中保留下来进行传输。好的，作为后续行动，因为我无法跟踪此存储库结构中的配置数据，是否有一种方法可以使用一个.gitignore文件从主存储库中排除一个或多个特定目录，然后如何创建文件树中存在的第二个git repo来跟踪实际的配置数据？我不抱太多希望，因为这是一个非常混乱和复杂的情况，以及我在过去20年中所学到的关于系统管理的所有知识

git checkout any-T-sub-i-commit

git checkout any-U-sub-j-commit