我有一个复杂的ansible工作流程。我有两个空气网络。我在两个网络上开发了剧本，所以我有两个由git管理的独立的ansible存储库。同时，大多数剧本都可以在两个地方使用。更复杂的是，这是一种单向转移。我可以从网络A转移到B，但不能从B转移到A.
我的模板文件包含与一个网络相关但与另一个网络无关的信息。我设计了它，以便文件名应该相同（以及Jinja2模板中的变量名称）。我希望能够创建一个排除文件的git包，这样当我从其他网络的存储库中取出包时，文件就不会被覆盖。因为在模板文件中包含错误信息可能会破坏整个环境，我需要在Git中跟踪Jinja2模板/变量文件。
除了使用.gitignore之外，是否有人有工作流推荐或git命令（因为需要跟踪文件以便我可以在紧急情况下回滚）这将有助于我实现这一目标？
答案 0 :(得分：3)
没有完全无关紧要的方法。
基本上，只有当它在索引中时，Git中的文件才会被跟踪。索引（通常，最初）从某个提交填充，因此它是一些先前的提交，用于确定是否要跟踪文件。假设存在一组提交 T 和 U ，除了提交 U 中的某些文件不在提交中Ť。然后：
git checkout any-T-sub-i-commit
导致文件在索引中（并因此被跟踪），而：
git checkout any-U-sub-j-commit
导致文件不在索引中（因此未跟踪）。
对于诸如合并之类的操作，更一般的方式也是如此：当您使用set T 的提交时，您可以使用具有文件的提交;当您使用set U 中的提交时，您将使用缺少文件的提交。如果将任何 T i 提交与任何 U j 提交合并，则对任何此类文件的影响 - 无论是＆ ＃39;添加，删除或冲突 - 取决于合并基础提交是否在集合 T 或集合 U ，以及对提交中这些文件的特定更改关于合并基础提交的 T i 。
当然，当文件移入或移出索引时，Git也会同时将它们复制到工作树中或从工作树中删除它们（通常谨慎的做法是不删除未保存但很珍贵的数据） 。因此，这意味着工作树文件将消失并重新出现，具体取决于您是否签出 T 提交或 U 提交。
与此同时，让我们看看捆绑是什么，至少在抽象意义上。捆绑包的本质是它包含至少 git fetch或git push在git fetch或{{1}后通过网络发送的所有数据用于最小化此数据的通信过程。 （它可以包含额外的数据，这些数据将被忽略。）这个最小的数据包含所有必须复制的对象 - 带注释的标签，提交，树和blob - 以及引用名称及其值。
要从捆绑包中排除某些文件集，您需要专门捆绑 U 提交，而不是任何 T 提交。这样做很好：如果你有所有分支重复，并通过分支名称区分 T 提交和 U 提交，你可以实现这一点容易。但结果是，每次进行新的 T 提交时，都必须进行相应的 U 提交，反之亦然。实际上，您的工作量增加了一倍。
适用于配置文件的标准建议通常也适用于此：不要提交任何配置。仅提交示例或默认或模板配置。使用某种包装器将这些示例配置转换为实际配置。 （当然，如果您自己编写了某些内容，例如shell脚本或Python程序或其他内容，也可以提交包装器。）您现在可以维护和版本控制这些示例/默认配置。克隆存储库获取样本，并从克隆更新 - git push，然后合并或重新绑定 - 更新样本，但不接触实际配置。根据包装器的智能程度以及输出格式中可用的内容， 1 它甚至可以自动检测样本/默认输入是否已更改，并警告或失败任何使用的运行指定的工具（即包装器本身），直到更新实际配置以匹配来自样本/默认/模板配置的任何所需更改。
这仍然不是微不足道的 - 特别是，您可能必须编写一个包装器，并以正确的方式教育用户运行您的特定系统。但它可能会达到你所能达到的微不足道的程度。
1 在这种特殊情况下，您的输出很可能是ansible的YAML文件。这意味着您可以在注释中隐藏各种有用的sample / default-config信息，例如。