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

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

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

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

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

从根本上来说，文件是tracked在 Git 中当且仅当它在索引中。索引（通常，最初）是从某个提交填充的，因此是某个先前的提交决定是否要跟踪文件。假设存在提交集T and U类似，只是有些文件不在提交中U提交中的T. Then:

git checkout any-T-sub-i-commit

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

git checkout any-U-sub-j-commit

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

The same holds in a more general fashion for operations like merging: when you work with commits from set T, you work with the ones that have the files; when you work with commits from set U, you work with the ones that lack the files. If you merge any T_i commit with any U_j commit, the effect on any such file—whether it's added, removed, or conflicted—depends on whether the merge-base commit is in set T or set U, and the specific changes to those files within commit T_i with respect to the merge base commit.

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

同时，让我们看看什么是捆绑，至少在抽象意义上是这样。捆绑包的本质在于它包含at least所有的数据git fetch or git push会通过电线发送，之后git fetch or git push用于最小化这些数据的通信过程。 （它可以包含额外的数据，这些数据将被忽略。）这个最小数据包含必须复制的所有对象（带注释的标签、提交、树和 blob）以及引用名称及其值。

要从捆绑包中排除某些文件集，您需要专门捆绑U承诺，而不是任何T承诺。就目前而言，这很好：如果您复制了所有分支，并区分T提交并U通过分支名称提交，您可以很容易地实现这一点。但结果是每次你制作一个新的Tcommit 你必须做出相应的U提交，反之亦然。事实上，你的工作量增加了一倍。

The standard recommendation that applies to configuration files in general applies here as well: Do not commit any configuration, ever. Commit only sample or default or template configurations. Use some kind of wrapper to convert these sample configurations to real configurations. (The wrapper can also be committed, of course, if it's something you write yourself, such as a shell script or Python program or whatever.) You may now maintain, and version-control, these sample / default configurations. Cloning the repository obtains the samples, and updating from the clone—git fetch followed by a merge or rebase—updates the samples, but does not touch the actual configuration. Depending on how smart the wrapper is and what's available in your output format,¹ it can even auto-detect that the sample/default input has changed, and warn or fail any runs that use the prescribed tool (i.e., the wrapper itself) until the real configuration is updated to match any required changes coming from the sample/default/template configuration.

这仍然不是微不足道的，特别是，您可能必须编写一个包装器，并教育用户运行特定系统的正确方法。但这是您可能实现的最微不足道的事情。

¹In this particular case, your output is most likely the YAML files for ansible. This means you can hide all kinds of useful sample/default-config information in comments, for instance.