使用Git与Subversion一起工作：忽略已跟踪文件的修改

Question

使用Git与Subversion一起工作：忽略已跟踪文件的修改

3

我目前使用Subversion存储库，但是用Git在本地工作。这使得工作变得更加容易，但同时也凸显了Subversion存储库中一些不良行为，给我带来了问题。

拉取代码后需要进行相当复杂的本地构建过程，并且会创建（并不幸地修改）许多文件。显然，这些更改并不打算提交回存储库。不幸的是，构建过程实际上正在修改一些已跟踪的文件（是的，很可能是因为有人误将这些构建生成物提交到Subversion存储库中）。由于这些都是修改，将它们添加到我的忽略文件中对我没有任何帮助。

我可以避免将这些更改提交回去，只需不进行暂存或提交即可，但是未暂存的本地更改意味着在清理之前无法进行变基。

我想知道是否有方法忽略一组已跟踪的文件的未来更改？或者，是否有其他处理此问题的方法，还是我必须告诉提交这些文件的人去清理它们？

- Chris Nicola

2个回答

1

除非出现了严重的政治脑损伤，否则从源代码控制中删除工件是正确的步骤。（或者更确切地说，“最迅速”的步骤，它总是正确的步骤。）

我不知道有什么方法可以告诉git忽略对已跟踪文件的更改。

- Nathan Kidd

网页内容由stack overflow 提供, 点击上面的

可以查看英文原文，
原文链接

- VonC · Accepted Answer

如Nathan所说, 清理那些文件（取消跟踪它们）是明智的选择。

但如果你必须忽略已跟踪的文件（这不是 Git 忽略文件的本地方式：Git 只会忽略未跟踪的文件），你可以设置一个进程，将你想要忽略的文件内容复制并在提交时还原。

我最初认为，一个smudge/clean 进程，即一个gitattributes 过滤器驱动程序可以达到目的：

alt text

其中：

涂抹过程将复制这些文件（在更新工作树时）
一些修改在构建过程中发生
清理步骤（在提交期间）将使用步骤1中制作的副本擦除文件内容。

但是，正如此帖子中所述的那样，这意味着通过添加有状态上下文（即被涂抹/清理的文件的完整路径名）来滥用这种无状态文件内容转换。
而这明确违反了J.C. Hamano的规定：

虽然我最初考虑将“%P”与路径名插值，但最终我决定不这样做，以防止人们滥用过滤器进行有状态转换，该转换会根据时间、路径名、提交、分支等更改结果。

甚至Linus Torvalds在当时也对整个机制表示了保留。

我必须说，我显然不是一个玩游戏的粉丝，但这些差异非常干净。它们实际上有用吗？我不知道。我有点担心这对于任何实际使用该功能的用户意味着什么，但我必须承认干净的实现方式让我感到很迷人。我猜这能让我们少受一些抱怨，但我也怀疑人们最终会因此真正自毁，然后责怪我们，在我们支持这个功能并且人们想要“扩展语义”时，会在后面引起巨大的痛苦，而这些语义已经不再干净了。但我不确定这个论点有多少道理。我碰巧相信“给他们一条绳子”的哲学。我认为你可能会彻底搞砸这个，但是嘿，任何这样做的人只能怪自己。

因此，在Git中忽略一组跟踪文件的任何更改并添加某种保存/恢复机制的正确位置应该在hooks中：

post-checkout：在更新工作树后运行git checkout时调用。您可以在那里运行一个脚本来收集要忽略的所有文件并将它们保存在某个地方。
pre-commit：您可以运行第二个脚本，该脚本将在获取建议的提交日志消息并进行提交之前恢复这些文件的内容。