我删除了一些文件，它们在拉取请求中显示为已删除（请参见下面的图片）
如何在拉取请求中不显示这些文件？（也不要显示为已删除）
3个回答
2
我不需要它们，因为它们是自动生成的。它们已经被包含在.gitignore中了。
如果它们之前被跟踪过，那么您的PR将记录它们不再被跟踪（因此被删除），并且被忽略（git check-ignore -v -- a/generated/file应该在本地返回一个"忽略"规则）。
换句话说，这是预期的行为。
- VonC
2
你知道有什么方法可以覆盖这个吗？ - R.P
1@racheliganon 不是，考虑到应该交付的是：之前记录的那些文件的记录，现在已经被删除了。 - VonC
2
在 Git 中，每个提交都是每个文件的完整快照。
更准确地说，每个提交都包含一个完整的快照。其中有什么文件，那就是这些文件。
提交之间不存在差异。提交是一组文件，加上一些元数据。因此，要求提交之间的差异就像要求自由女神像之间的差异一样。
现在，我们可以询问自由女神像和纽约金融区乔治·华盛顿雕像之间的差异。或者更明智的是，我们可以询问金融区乔治·华盛顿雕像与联合广场的雕像之间的差异。但是我们必须选择两个事物进行询问。对于提交也是如此：我们不能在没有选择两个提交的情况下询问差异。
然而，这就是拉取请求（PR）的作用。当您使用 GitHub 发出拉取请求时，GitHub 会选择两个提交进行比较。您看到的差异就是比较这两个提交的结果。其中一个提交是您分支的最新提交，另一个提交位于 GitHub 所谓的基本分支中。（由于 Git 没有这个功能，因此我们在 Git 中必须做一些不同的事情，但我们可以在 Git 中获得相同的效果。）
如果 PR 显示这些文件已被删除，则意味着：
文件在基本提交中确实存在。
文件在拉取请求分支顶部提交中不存在。
如果您不希望删除这些文件，则必须创建一个新的分支顶部提交，其中这些文件存在。然后它们将不会被"删除"，而是在该提交中。
现在，一旦您进行了某些提交，就无法更改该提交。因此，您不能更改 PR 中现有的分支顶部提交。但是您不需要这样做。在 Git 中，分支名称始终表示该分支上的最新提交。如果您添加了更多提交，那么它们现在就是最新的提交。因此，您可以向该分支添加新提交以将文件放回。现在，分支顶部提交具有这些文件。或者，您可以从分支中剥离提交。这有点困难：Git 是建立在添加提交的基础上的，而不是剥离提交（剥离分支顶部的提交也不会删除提交：它只是使分支名称定位到一些较早的提交）。
更准确地说，每个提交都包含一个完整的快照。其中有什么文件，那就是这些文件。
提交之间不存在差异。提交是一组文件，加上一些元数据。因此，要求提交之间的差异就像要求自由女神像之间的差异一样。
现在，我们可以询问自由女神像和纽约金融区乔治·华盛顿雕像之间的差异。或者更明智的是，我们可以询问金融区乔治·华盛顿雕像与联合广场的雕像之间的差异。但是我们必须选择两个事物进行询问。对于提交也是如此：我们不能在没有选择两个提交的情况下询问差异。
然而，这就是拉取请求（PR）的作用。当您使用 GitHub 发出拉取请求时，GitHub 会选择两个提交进行比较。您看到的差异就是比较这两个提交的结果。其中一个提交是您分支的最新提交，另一个提交位于 GitHub 所谓的基本分支中。（由于 Git 没有这个功能，因此我们在 Git 中必须做一些不同的事情，但我们可以在 Git 中获得相同的效果。）
如果 PR 显示这些文件已被删除，则意味着：
文件在基本提交中确实存在。
文件在拉取请求分支顶部提交中不存在。
如果您不希望删除这些文件，则必须创建一个新的分支顶部提交，其中这些文件存在。然后它们将不会被"删除"，而是在该提交中。
现在，一旦您进行了某些提交，就无法更改该提交。因此，您不能更改 PR 中现有的分支顶部提交。但是您不需要这样做。在 Git 中，分支名称始终表示该分支上的最新提交。如果您添加了更多提交，那么它们现在就是最新的提交。因此，您可以向该分支添加新提交以将文件放回。现在，分支顶部提交具有这些文件。或者，您可以从分支中剥离提交。这有点困难：Git 是建立在添加提交的基础上的，而不是剥离提交（剥离分支顶部的提交也不会删除提交：它只是使分支名称定位到一些较早的提交）。
所有这些替代方案都不适用于您的情况
您在评论中说，这些文件“不应该”出现在提交中，因为它们是自动生成的。
但事实是，在某些提交中确实包含了这些文件。这个事实无法改变，因为这些提交无法更改。你最多只能停止使用这些提交，要么将它们留下来以不破坏提交历史，要么将它们剥离开来，使它们难以找到，以便没有人会使用它们（故意损坏历史）。在新的提交中不要包含这些文件。
任何PR都会将这些文件显示为已删除，因为它们是通过比较删除的。也就是说，git checkout或git switch --detach到旧的提交时提取这些文件：它们在旧的提交中。然后再切换到更新的提交，这些文件将被删除。
由于它们是自动生成的，所以删除它们是无害的。（如果这样做是有害的，它们就没有被正确地自动生成，也许不应该删除它们。）
删除这些文件并提交可能是正确的做法，这将显示为一次删除，这也是正确的。接受这个事实吧。在.gitignore中列出这些文件后，可以确保它们不会出现在未来的提交中，但是可能会有一些小缺点。您可能不会遇到这种情况。
如果自动生成这些文件非常慢，请考虑在一个特殊的分支上添加一些特殊的提交，该分支包含这些文件，并根据需要定期更新它们，然后允许人们运行git restore branch -- path/to/generated/files。这个分支只能包含生成的文件，因为人们将使用git restore来填充他们的工作树（而不是索引/暂存区）。
- torek
12
1取决于你所说的“这个”。文件要么存在，要么不存在。比较可以告诉你提交 L（左侧）和提交 R（右侧）之间文件的差异。当文件不同或缺失时，你不能有一个比较说“文件是相同的”：那将是虚假的。 - torek
1@Binarian：这样做是可行的，但Git会巧妙地去重相同的文件。如果您只更改了那个1GB文件的一个字节，您将看到存储库的大小会增加很多。由于视频文件通常是预压缩的，Git的压缩（前期和后期的对象打包）在这里也不会有太大帮助。 - torek
1请注意，一些现代文件系统（例如ZFS）在创建文件系统快照时使用相同的技巧。它们将原始文件标记为“写时复制”（好吧，ZFS是这样做的，但是在块级别而不是整个文件级别；还有其他技术）。 - torek
1从技术上讲，提交对象本身仅包含元数据（名称、父级等）；其中一个元数据行读取“tree <hash>”。它是代表快照的“tree”对象。树形对象根据需要递归：每个树形对象都包含（名称、模式、哈希）元组，其中“名称”部分只是组件名称。哈希值可以是进一步的树哈希，也可以是在某些其他存储库中找到的blob哈希或（对于保存的gitlink条目）提交哈希ID。 - torek
1本质上，而且Linus Torvalds自己也多次强调过，Git是一个带有检查点功能的用户空间文件系统的实现。提交包含（未计算但可垃圾回收的）链接到“目录”（树，它们充当了组合dir+inode的作用）和文件内容（blob）。UI建立在该文件系统实现之上，但是如果您想进行特殊技巧，则
git hash-object，git mktree，git write-tree和git commit-tree会暴露出来。例如，旧的git stash脚本就使用此功能来创建其两个或三个stash提交。 - torek显示剩余7条评论
1
如果这些文件对你的代码库很重要，那么当它们被添加、删除或修改时，将它们列入拉取请求是有意义的。如果你不想这样做，那可能意味着这些文件并不那么重要，那么你可以将它们添加到.gitignore文件中。
- Juvanis
1
我不需要它们，因为它们是自动生成的。它们在 .gitignore 中。 - R.P
网页内容由stack overflow 提供, 点击上面的可以查看英文原文，
原文链接
原文链接