我目前正在使用 subversion 存储库，但我正在使用 git 在我的机器上本地工作。它使工作变得更容易，但它也使 subversion repo 中发生的一些不良行为非常明显，这给我带来了问题。
拉下代码后有一个有点复杂的本地构建过程，它会创建（不幸的是修改）许多文件。显然，这些更改并不意味着要提交回存储库。不幸的是，构建过程实际上是在修改一些被跟踪的文件（是的，很可能是因为有人在某个时候错误地将这些构建工件提交到了 subversion 存储库）。由于这些是修改，因此将它们添加到我的忽略文件对我没有任何作用。
我可以避免检查这些更改，我简单地不暂存或提交它们，但是有未暂存的本地更改意味着我不能在不先清理它们的情况下进行变基。
我想知道的是，是否有任何方法可以忽略未来对一组跟踪文件的更改？或者，是否有另一种方法来处理我遇到的问题，或者我只需要告诉签入这些文件的人来清理它们？
正如Nathan 所说，清理这些文件（取消跟踪它们）是明智之举。
但是，如果您必须忽略跟踪文件（这不是 Git 忽略文件的原生方式：Git 只忽略非跟踪文件），您可以设置一个过程，复制您要忽略的文件内容，并在提交时恢复.
我最初认为涂抹/清洁过程，即gitattributes 过滤器驱动程序可以解决问题：
， 在哪里：
但是，正如本文所述，这意味着通过添加有状态上下文（即被涂抹/清理的文件的完整路径名）来滥用这种无状态文件内容转换。
JC Hamano 明确禁止这样做：
尽管我最初考虑
%P使用路径名插入“”，但我最终决定反对它，以阻止人们滥用过滤器进行状态转换，从而根据时间、路径名、提交、分支和其他内容更改结果。
甚至当时 Linus Torvalds 也对 all 机制有所保留：
我不得不说，我显然不是玩游戏的忠实粉丝，但差异非常干净。
它们真的有用吗？我不知道。我有点担心这对于该功能的任何实际用户意味着什么，但我不得不承认我被一个干净的实现迷住了。
我怀疑这会引起我们的一些抱怨，但我也怀疑人们最终会真的用这样的事情搞砸自己，然后指责我们并在我们支持这一点并且人们想要时造成巨大的痛苦”扩展语义”不再干净。
但我不确定这个论点到底有多有效。我碰巧相信“给他们绳子”的哲学。我认为您可能会因此而自暴自弃，但是，嘿，这样做的人只能怪他自己
因此，添加某种保存/恢复机制（并有效地忽略对Git中一组跟踪文件的任何更改）的正确位置将是hooks：
post-checkout：在更新工作树后运行 git checkout 时调用。在那里，您可以运行一个脚本来收集所有要忽略的文件并将它们保存在某处。
pre-commit：在获取建议的提交日志消息并进行提交之前，您可以运行第二个脚本来恢复这些文件的内容。
除非发生严重的政治脑损伤，否则从源代码控制中删除工件是正确的步骤。（或者更确切地说，“最方便”的步骤，它始终是正确的步骤。）
我不知道有一种方法可以告诉 git 忽略对跟踪文件的更改。