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