2012年1月兰德尔·施瓦茨发表了演讲Git 简介我非常喜欢，但我对他的警告感到困惑不是使用 git 来跟踪具有不相关或单独历史记录的单个文件。
幻灯片第 4 页包含以下要点...
但不是为了...
- 跟踪文件权限和所有权
- 跟踪具有单独历史记录的单个文件
- 让事情变得痛苦
......以下是他在大约 4 分钟后所说的话：
它没有针对文件的任何元数据进行优化。它不，它不是，跟踪文件权限或文件所有权。这不是它的工作。它管理源文件，源文件没有所有者，源文件没有权限。源文件用于构建您要部署的真实内容。因此，git 没有这方面的技术。人们曾尝试在它的基础上构建结构来实现这一点，并取得了一定程度的成功，但实际上，让我们看看 git 的基本用途，而不是人们在它的基础上构建的内容。
它也不适用于跟踪具有不相关或独立历史记录的单个文件。例如，您可能会想，“哦，我真的很喜欢这个。我想用它来跟踪我所有的等等。但等等实际上是一堆独立的、不相关的文件。你不会进行分支和合并……将这个更改添加到那个更改中，并最终希望同时撤消它们。它实际上不是那样工作的。所以它对单个文件来说并不好。
我仍然使用 RCS 来跟踪我的 /etc 中的单个文件。它非常快，成本低，而且我可以返回我需要的数据。它也没有针对使事情变得痛苦而进行优化。好吗？它的设计很简单。
就我个人而言，我并没有计划使用 git 来跟踪我的 /etc，但我最近开始使用 git 来跟踪 /var/named（BIND 配置）。鉴于 Randal 上面所说的，我是否应该停止为此使用 git？是否存在缺点、我没有预料到的问题或陷阱？到目前为止，一切都按我预期的那样运行，我没有遇到任何问题，但由于上述警告，我实际上犹豫是否开始使用 git 来跟踪 /var/named。
我受到scm_track_enabled的特征皮匠其含义是“在执行添加、编辑或同步事件时启用触发器，该触发器控制对 /var/lib/cobbler 的所有更改。这可用于恢复到以前的数据库版本、生成 RSS 源或用于其他审计或备份目的。git 是推荐的 SCM，可与此功能配合使用。”我对 git 和 /var/named 的使用与此非常相似。
（顺便说一句，我从来没有使用过雷达反射截面并且当我已经对 git 有了相当的了解时，我无法想象还要费心去学习它，即使它很容易。）
具体来说，我想了解使用 git 来跟踪 /var/named，但我欢迎有关使用 git 跟踪类似目录的最佳实践的答案。
答案1
这已经偏离了“相当主观”的范畴。但是...
我认为使用 git 来跟踪这类事情并没有什么不妥。是的，它是为跟踪大型、复杂的相互关联的源文件集合而构建的。但这并不意味着它不适合跟踪小型的不相关文件集合。
就我个人而言，我使用etckeeper/etc使用 git 后端在我的服务器上进行跟踪。效果很好。从 Ubuntu 的 apt repo 安装时，它会带有很好的 apt 挂钩，因此它会在安装每个新软件包时自动启动提交。非常方便。
无论如何，尝试一下，它不会造成任何东西的伤害，如果您最终想要在将来切换到另一个版本控制系统，那么有很多可用的迁移工具。
答案2
确实是主观领域。我不喜欢 etckeeper，它所做的就是创建非常混乱的 /etc 历史记录。现在对于 /var/named（我假设这是定义区域的地方）来说，它可能会更好，特别是如果您只有几个区域，但它仍然是一个丑陋的黑客。
我发现“正确”的做法是使用木偶或类似的其他配置管理软件。您无需配置服务器，只需编写 Puppet 代码来配置服务器即可。我使用 mercurial（但您也可以使用 git）来管理 Puppet 代码的存储库。分支和合并很有用（例如，您正在处理一个新配置，您不确定它是否经过了足够的测试，然后您必须紧急修复生产服务器中的问题；在这种情况下，您可以从稳定版本进行分支，然后进行合并）。Puppet+DVCS 的组合非常有用且非常干净，但 Puppet 是一个小野兽，需要一点时间来驯服，而且由于区域序列号的原因，使用 Puppet 进行绑定特别棘手。
更新：
我一直在思考这个问题，我倾向于得出这样的结论：使用 git 来跟踪 /var/named 并没有什么错，而且这不是一个丑陋的黑客行为。是的，这些文件是相关的。是的，您可能希望克隆以对配置进行认真的修订，分支以在修订时维护生产配置，并在完成修订后进行合并（尽管所有这些可能都不常见）。
有点离题，但是 bind 的配置有两点我不喜欢。首先，为了添加区域，我需要添加/修改两个文件：named.conf 和区域文件。这不必要地复杂。我更喜欢类似于 apache 的设置，区域文件位于 /etc/bind/zones-available 中，从 /etc/bind/zones-enabled 符号链接，无需触碰 named.conf。其次，序列号很麻烦。我们主要自动化它们的维护；在 Puppet 管理的机器上，我有一个修复它们的 shell 脚本，在其他机器上，我使用 vim 插件。我们自动化它们的事实意味着它们很可能不存在。可以使用文件时间戳来代替。序列号会在存储库历史记录中造成一些丑陋，但这是 bind 的问题，而不是 git 的问题，也不是使用 git 跟踪 bind 配置的实践的问题。
答案3
问你自己...
如果它覆盖了所有 /etc，我是否会“恢复”到 git 中的某个特定提交？
如果提交涵盖了所有 /etc，我是否会将其“合并”到我当前状态？
我猜答案是“不，不，不”。
如果是这样，git 就是错误的工具。Git 跟踪的是文件树，而不是单个文件。这就是我主张对单个文件使用 RCS 的原因。