混帐尝试推送不存在的文件...清除缓存后

本文介绍了混帐尝试推送不存在的文件...清除缓存后的处理方法，对大家解决问题具有一定的参考价值，需要的朋友们下面随着小编来一起学习吧！ 问题描述 29岁程序员，3月因学历无情被辞！ 我的回购库中有许多shapefile文件太大，从而导致我推送GitHub失败。我最初尝试创建一个不包含shapefile束中大部分扩展名的 .gitignore 文件。它仍然试图推动形状文件。搜索后，我发现我必须清除缓存： git add。 然而，一旦我尝试提交并再次推送，我发现这并没有解决问题。相同的shapefile被挂起来了。在经历了很多混乱之后，我放弃了这个想法，并决定将所有shapefile移出回购。我再次清除缓存，加回来，承诺，并试图推送到GitHub。 推送失败。 shapefile（不再在回购中）对于推送来说太大了。这怎么可能发生？我觉得不在提交中的文件，因为它们不在回购站中，因此不应该挂起推送。任何关于这里发生的事情的想法都将得到最多赞赏。 更新：重新贷款选项的当前状态... noop ＃Rebase 133c6ec..133c6ec到133c6ec ＃＃命令：＃p，pick =使用提交＃r，reword =使用提交，但编辑提交消息＃e，edit = use commit，但是停止修改＃s，squash =使用提交，但融入前面的提交＃f，fixup = likesquash，但放弃此提交的日志消息＃x，exec =运行命令（该行的其余部分）使用shell ＃＃这些行可以重新排序;他们从上到下执行。 ＃＃如果你在这里删除一行，那么COMMIT将会丢失。 ＃＃但是，如果您删除了所有内容，那么rebase将被中止。 ＃＃注意空提交被注释掉 UPDATE ： Reflog >>全部以'添加许多图片'开头 133c6ec HEAD @ {0}：rebase - 我（完成）：返回refs / heads / master 133c6ec HEAD @ {1}：rebase -i（开始）：checkout refs / remotes / origin / master 133c6ec HEAD @ {2}：rebase -i（完成）：返回refs / heads / master 133c6ec HEAD @ {3}：rebase -i（开始）：checkout refs / remotes / origin / master 133c6ec HEAD @ {4}： rebase -i（完成）：返回refs / heads / master 133c6ec HEAD @ {5}：rebase -i（开始）：checkout refs / remotes / origin / master 133c6ec HEAD @ {6} ：rebase -i（finish）：返回refs / heads / master 133c6ec HEAD @ {7}：rebase -i（pick）：仍然处理shp bs 0f81c71 HEAD @ {8}：rebase -i（选择）：删除shapefile 91cb472 HEAD @ {9}：rebase -i（挑选）：添加来自Mullins的评论请参阅 - throu 83c1269 HEAD @ {10}：rebase -i ：添加来自Mu的评论llins咨询 - thro 7677b3f HEAD @ {11}：rebase -i（选择）：希望.gitignore现在可以工作 97aa005 HEAD @ {12}：rebase -i（选择）：调整gitignore 9e912cb HEAD @ {13}：rebase -i（选择）：调整gitignore 06647c0 HEAD @ {14}：rebase -i（squash）：添加许多图片 259d73b HEAD @ {15}： rebase -i（squash）：＃这是2个提交的组合。 3b2d5e8 HEAD @ {16}：rebase -i（开始）：checkout refs / remotes / origin / master a585f1d HEAD @ {17}：rebase：放弃 7bc98a4 HEAD @ {18} ：rebase -i（开始）：checkout refs / remotes / origin / master a585f1d HEAD @ {19}：rebase -i（完成）：返回refs / heads / master a585f1d HEAD @ {20 }：rebase -i（start）：checkout 9f28970 a585f1d HEAD @ {21}：rebase -i（完成）：返回refs / heads / master a585f1d HEAD @ {22}：rebase -i （开始）：checkout refs / remotes / origin / master ：...跳过... 133c6ec HEAD @ {0}：rebase -i（完成）：返回refs / heads / master 133c6ec HEAD @ {1}：rebase -i（开始）：checkout refs / remotes / origin / master 133c6ec HEAD @ {2}：rebase -i（完成）：返回refs / heads / master 133c6ec HEAD @ {3}：rebase -i（开始）：checkout refs / remotes / origin / master 133c6ec HEAD @ {4}：rebase -i（完成）：返回refs / heads / master 133c6ec HEAD @ {5}：rebase -i（开始）：checkout refs / remotes / origin / master 133c6ec HEAD @ {6}：rebase -i（f inish）：返回refs / heads / master 133c6ec HEAD @ {7}：rebase -i（pick）：仍然处理shp bs 0f81c71 HEAD @ {8}：rebase -i（pick） ：删除shapefile 91cb472 HEAD @ {9}：rebase -i（挑选）：添加来自Mullins的评论参考 - throu 83c1269 HEAD @ {10}：rebase -i（挑选）：添加来自Mullins的评论咨询 - thro 7677b3f HEAD @ {11}：rebase -i（pick）：希望.gitignore现在可以工作 97aa005 HEAD @ {12}：rebase -i（pick）：调整gitignore 9e912cb HEAD @ {13}：rebase -i（选择）：调整gitignore 06647c0 HEAD @ {14}：rebase -i（squash）：添加许多图片 259d73b HEAD @ {15}：rebase -i（squash）：＃这是2个提交的组合。 3b2d5e8 HEAD @ {16}：rebase -i（开始）：checkout refs / remotes / origin / master a585f1d HEAD @ {17}：rebase：放弃 7bc98a4 HEAD @ {18} ：rebase -i（开始）：checkout refs / remotes / origin / master a585f1d HEAD @ {19}：rebase -i（完成）：返回refs / heads / master a585f1d HEAD @ {20 }：rebase -i（start）：checkout 9f28970 a585f1d HEAD @ {21}：rebase -i（完成）：返回refs / heads / master a585f1d HEAD @ {22}：rebase -i （开始）：checkout refs / remotes / origin / master a585f1d HEAD @ {23}：rebase：aborting ：...跳过... 133c6ec HEAD @ {0}：rebase -i（完成）：返回refs / heads / master 133c6ec HEAD @ {1}：rebase -i（开始）：checkout refs / remotes / origin / master 133c6ec HEAD @ {2}： rebase -i（完成）：返回refs / heads / master 133c6ec HEAD @ {3}：rebase -i（开始）：checkout refs / remotes / origin / master 133c6ec HEAD @ {4} ：rebase -i（完成）：返回refs / heads / master 133c6ec HEAD @ {5}：rebase -i（开始）：checkout refs / remotes / origin / m aster 133c6ec HEAD @ {6}：rebase -i（finish）：返回refs / heads / master 133c6ec HEAD @ {7}：rebase -i（pick）：仍然处理shp bs 0f81c71 HEAD @ {8}：rebase -i（挑选）：删除shapefile 91cb472 HEAD @ {9}：rebase -i（挑选）：添加来自Mullins的评论参考 - 通过rev章节 83c1269 HEAD @ {10}：rebase -i（pick）：添加来自Mullins的评论 - 通过rev章节 7677b3f HEAD @ {11}：rebase -i（pick）：希望.gitignore现在可以工作 97aa005 HEAD @ {12}：rebase -i（挑选）：调整gitignore 9e912cb HEAD @ {13}：rebase -i（挑选）：调整gitignore 06647c0 HEAD @ {14}：rebase - 我（squash）：添加许多图片 259d73b HEAD @ {15}：rebase -i（squash）：＃这是2个提交的组合。 3b2d5e8 HEAD @ {16}：rebase -i（开始）：checkout refs / remotes / origin / master a585f1d HEAD @ {17}：rebase：放弃 7bc98a4 HEAD @ {18} ：rebase -i（开始）：checkout refs / remotes / origin / master a585f1d HEAD @ {19}：rebase -i（完成）：返回refs / heads / master a585f1d HEAD @ {20 }：rebase -i（start）：checkout 9f28970 a585f1d HEAD @ {21}：rebase -i（完成）：返回refs / heads / master a585f1d HEAD @ {22}：rebase -i （开始）：checkout refs / remotes / origin / master a585f1d HEAD @ {23}：rebase：aborting eaadebf HEAD @ {24}：rebase -i（选择）：从Mullins中添加评论咨询 - 通过rev章 7bc98a4 HEAD @ {25}：rebase -i（开始）：checkout refs / remotes / origin / master a585f1d HEAD @ {26}：commit：仍处理shp bs 4bef02c HEAD @ {27}：commit：删除shapefile cc061ac HEAD @ {28}：commit：添加来自Mullins的评论 - 通过rev章节 21c5ab7 HEAD @ {29}：commit：添加评论Mullins通过rev章节进行咨询 9f28970 HEAD @ {30}：commit：希望.gitignore现在可以工作 a2bdbae HEAD @ {31}：commit：调整gitignore c3e5128 HEAD @ {32}：commit：调整gitignore 8f8b96e HEAD @ {33}：commit：添加gitignore以避免跟踪shapefile 0c14e14 HEAD @ {34}：commit：添加gitignore以避免跟踪shapefile 3b2d5e8 HEAD @ {35}：commit：添加许多图片 解决方案这里要记住的第一件事是 git push 推送提交。如果有任何文件碰巧被包含，那纯粹是被推送的提交所需的。 要记住的第二件事当你执行 git push 时，你的git和他们的git（在这种情况下是在github上运行的git命令）通常会彼此交谈，形式： 我已经提交< SHA-1> 我想给你，然后我希望你设置你的分支 master （或其他分支）指向那个SHA-1。 那么，我对该分支有<不同的SHA-1> ，告诉我什么是SHA -1s我需要在我拥有的和你拥有的之间填补任何漏洞。 （除此之外还有更多，它有不同的顺序，但本质是交换who-has-what提交和其他对象ID。） > 一旦他们知道对方有什么ID，发送方会打包任何需要的：这是一系列提交（可能为空）和任何实体 - 主要限于）文件 - 与那些提交一起使用，即接收器还没有。在这种情况下，发件人是你的git，接收者是他们的git，并且包中包含一些大文件。 您决定要使用而不是发送大文件。这意味着你必须替换你要求你的git发送的提交，并且你会要求你的git发送一些新的提交。如果新提交不是引用大文件，那么当你的git发送提交时，他们的git也不会请求这些文件，你的git也不会发送它们。 Pro Git book 有关于重写历史记录的章节，其中涵盖了这相当好。缺少什么（至少如果你只是阅读一节，其他章节可以涵盖这一点）是一个rebase真正的功能。 （顺便说一句，你的git repo仍然会包含大文件，并且会继续这样做，直到这些文件的所有引用都不存在为止，包括那些滞留在git的reflogs 历史重写操作之后，如果你在重写历史记录时犯了一个错误，这些残留的鬼魂可以让你重新生成文件。默认情况下Reflog条目会持续30天，因为这些条目至少 - 更加活跃的引用日志条目会持续存在默认情况下为90天 - 但除非你做了一些不寻常的事情，否则你通常可以让它们自己过期。） git rebase 文档有一些图表，比如这个： A --- B --- C主题 / D --- E --- F --- G master [成为] A' - B' - C'主题 / D --- E --- F --- G主 单个字母代表提交，其原因是 A'而不是 A 等等，在rebase之后，rebase doesn't- 不能 - 实际上移动提交，它只能创建一个副本。原始提交仍然存在，它们只是没有像主题这样的标签保持可见。如果副本不同 - 而且他们是 - 那么他们有一个新的，不同的SHA-1。至少在推送（和提取）期间，这是SHA-1的真正重要。 在你的情况中，当重新绑定的时候你想要做的是故意瑕疵的复印件，其中原件具有大型文件，而有缺陷的复印件没有。 （实际上，拥有大文件就是缺点，所以不完全完美的副本是正确的，这是原始的错误！） 交互式重新绑定具有将新提交挤压到现有提交中的额外功能，即根据 next 提交来获取它将要制作和修改的副本在这个序列中。 你想要做的和上面的图表之间的另一个很大的区别是你希望新的提交（S）开始从与原件相同的点：$ b​​ $ b H - I< - master [在您的回购] / ... - G< - origin / master [即github上的内容] 这里提交 H 可能是带有额外文件的缺陷，并且 I 可能是提交删除额外的文件。如果您要求将 master 推送到github并让github将它设置为 master ，那么您的git和它们的git将会聊天并决定github需要 H 和 I 以及一些文件 - 包括因为 H 如果您重写自己的历史记录，以取代 H 和 I 你有一个新的 H'I'提交 - 我们只需调用 J 为简单起见，那么您将得到这个图表： H - I [弃用ghosts] / ... - G \ J 现在你可以让你的git调用github的git，并建议只发送 J ，其中没有大文件。 请注意，所有这些都有两个键： 提交 G （如 origin / master 指向的）没有大文件，但在中你的仓库和github上的仓库。这是推送的共同出发点：这是推送时您的第一次提交 的第一个提交，因为它们已经有了它。 提交 J （和/或您要推送的任何其他提交）必须 没有大文件。这样，当你的git与他们的git交谈时，你的git将决定它需要发送的内容不包括大文件。 最后，无论您的方在推送中发送多少次提交，重要的是这些特定提交中的 。只要你喜欢，你可以重写只有你有的东西，但是你喜欢它。一旦你成功地将这些提交交给了另一个存储库，如果你将它们重写为新的稍微不同的副本，其他repo 仍然有原始文件，并且其他用户也可能获得了它们如果该其他存储库通常是可访问的）。 （You can 仍然可以重写历史记录并使用 - 强迫推动请求另一个repo放弃一些提交，包括你认为是不好的原始文件，这也不是什么固有的错误，只是任何与你合作的人都可能选择了这些错误的原件，他们可能会使用它们，所以你也为这些人做了更多的工作。） git rebase -i 显示一个空列表：这表明你实际上已经删除了所有未提交的提交。也就是说，而不是从： H - I / 。 .. - G< - origin / master to： J / ... - G 你不知道怎么舍弃 H 和 I ，这样您的 master 也指向提交 G 。 如果你做了 rebase -i 并告诉git squash I 转换为 H ，并且它的结果与commit 。 （例如，如果从 G 到 H 的唯一区别是添加大文件，唯一的区别是 H 至 I 为删除大文件，两者的组合为 no 不同于 G 。）Git确实允许空白提交 - 与通常一样提交作者，消息等，但与相同 tree作为之前的提交 - 但默认情况下， rebase 假定您不希望这样：它只是完全删除提交的提交。 如果您确实有其他提交已经消失，那么我之前提到的那些鬼提交就是您所需要的。要找到它们，请查看reflogs： $ git reflog 和： $ git reflog master 这些reflog保留了 HEAD 和 master （或任何其他分支）已指出最近90天：两个提交的原始SHA-1 ID，无论它们是常规提交永远存在，或者只留下reflog条目留下的鬼魂提交。 I have a number of shapefiles in my repo that were too large, thereby causing my push to GitHub to fail. I initially tried to create a .gitignore file that excludes most of the extensions in shapefile bundles. It still tried to push the shapefiles. After some searching, I found I had to clear the cache:git rm -rf --cached .git add .However, once I tried to commit and then push again, I found that this did not fix the problem. The same shapefile was hanging things up. After much messing around, I abandoned the idea and decided to move all the shapefiles out of the repo. I cleared the cache again, added back, committed, and attempted to push to GitHub.The push failed. The shapefile (which is no longer in the repo) was too large for a push. How can that happen? I feel like files that are not in the commit, because they aren't in the repo, should not be able to hang up the push. Any thoughts on what is happening here would be most appreciated.UPDATE: Current status of rebase options...noop# Rebase 133c6ec..133c6ec onto 133c6ec## Commands:# p, pick = use commit# r, reword = use commit, but edit the commit message# e, edit = use commit, but stop for amending# s, squash = use commit, but meld into previous commit# f, fixup = like "squash", but discard this commit's log message# x, exec = run command (the rest of the line) using shell## These lines can be re-ordered; they are executed from top to bottom.## If you remove a line here THAT COMMIT WILL BE LOST.## However, if you remove everything, the rebase will be aborted.## Note that empty commits are commented outUPDATE: Reflog >> it all starts with 'Adding many images'133c6ec HEAD@{0}: rebase -i (finish): returning to refs/heads/master133c6ec HEAD@{1}: rebase -i (start): checkout refs/remotes/origin/master133c6ec HEAD@{2}: rebase -i (finish): returning to refs/heads/master133c6ec HEAD@{3}: rebase -i (start): checkout refs/remotes/origin/master133c6ec HEAD@{4}: rebase -i (finish): returning to refs/heads/master133c6ec HEAD@{5}: rebase -i (start): checkout refs/remotes/origin/master133c6ec HEAD@{6}: rebase -i (finish): returning to refs/heads/master133c6ec HEAD@{7}: rebase -i (pick): still dealing with shp bs0f81c71 HEAD@{8}: rebase -i (pick): Removing shapefiles91cb472 HEAD@{9}: rebase -i (pick): Adding comments from Mullins consult - throu83c1269 HEAD@{10}: rebase -i (pick): Adding comments from Mullins consult - thro7677b3f HEAD@{11}: rebase -i (pick): Hopefully .gitignore is now working97aa005 HEAD@{12}: rebase -i (pick): Adjusting gitignore9e912cb HEAD@{13}: rebase -i (pick): Adjusting gitignore06647c0 HEAD@{14}: rebase -i (squash): Adding many images259d73b HEAD@{15}: rebase -i (squash): # This is a combination of 2 commits.3b2d5e8 HEAD@{16}: rebase -i (start): checkout refs/remotes/origin/mastera585f1d HEAD@{17}: rebase: aborting7bc98a4 HEAD@{18}: rebase -i (start): checkout refs/remotes/origin/mastera585f1d HEAD@{19}: rebase -i (finish): returning to refs/heads/mastera585f1d HEAD@{20}: rebase -i (start): checkout 9f28970a585f1d HEAD@{21}: rebase -i (finish): returning to refs/heads/mastera585f1d HEAD@{22}: rebase -i (start): checkout refs/remotes/origin/master:...skipping...133c6ec HEAD@{0}: rebase -i (finish): returning to refs/heads/master133c6ec HEAD@{1}: rebase -i (start): checkout refs/remotes/origin/master133c6ec HEAD@{2}: rebase -i (finish): returning to refs/heads/master133c6ec HEAD@{3}: rebase -i (start): checkout refs/remotes/origin/master133c6ec HEAD@{4}: rebase -i (finish): returning to refs/heads/master133c6ec HEAD@{5}: rebase -i (start): checkout refs/remotes/origin/master133c6ec HEAD@{6}: rebase -i (finish): returning to refs/heads/master133c6ec HEAD@{7}: rebase -i (pick): still dealing with shp bs0f81c71 HEAD@{8}: rebase -i (pick): Removing shapefiles91cb472 HEAD@{9}: rebase -i (pick): Adding comments from Mullins consult - throu83c1269 HEAD@{10}: rebase -i (pick): Adding comments from Mullins consult - thro7677b3f HEAD@{11}: rebase -i (pick): Hopefully .gitignore is now working97aa005 HEAD@{12}: rebase -i (pick): Adjusting gitignore9e912cb HEAD@{13}: rebase -i (pick): Adjusting gitignore06647c0 HEAD@{14}: rebase -i (squash): Adding many images259d73b HEAD@{15}: rebase -i (squash): # This is a combination of 2 commits.3b2d5e8 HEAD@{16}: rebase -i (start): checkout refs/remotes/origin/mastera585f1d HEAD@{17}: rebase: aborting7bc98a4 HEAD@{18}: rebase -i (start): checkout refs/remotes/origin/mastera585f1d HEAD@{19}: rebase -i (finish): returning to refs/heads/mastera585f1d HEAD@{20}: rebase -i (start): checkout 9f28970a585f1d HEAD@{21}: rebase -i (finish): returning to refs/heads/mastera585f1d HEAD@{22}: rebase -i (start): checkout refs/remotes/origin/mastera585f1d HEAD@{23}: rebase: aborting:...skipping...133c6ec HEAD@{0}: rebase -i (finish): returning to refs/heads/master133c6ec HEAD@{1}: rebase -i (start): checkout refs/remotes/origin/master133c6ec HEAD@{2}: rebase -i (finish): returning to refs/heads/master133c6ec HEAD@{3}: rebase -i (start): checkout refs/remotes/origin/master133c6ec HEAD@{4}: rebase -i (finish): returning to refs/heads/master133c6ec HEAD@{5}: rebase -i (start): checkout refs/remotes/origin/master133c6ec HEAD@{6}: rebase -i (finish): returning to refs/heads/master133c6ec HEAD@{7}: rebase -i (pick): still dealing with shp bs0f81c71 HEAD@{8}: rebase -i (pick): Removing shapefiles91cb472 HEAD@{9}: rebase -i (pick): Adding comments from Mullins consult - through rev chapter83c1269 HEAD@{10}: rebase -i (pick): Adding comments from Mullins consult - through rev chapter7677b3f HEAD@{11}: rebase -i (pick): Hopefully .gitignore is now working97aa005 HEAD@{12}: rebase -i (pick): Adjusting gitignore9e912cb HEAD@{13}: rebase -i (pick): Adjusting gitignore06647c0 HEAD@{14}: rebase -i (squash): Adding many images259d73b HEAD@{15}: rebase -i (squash): # This is a combination of 2 commits.3b2d5e8 HEAD@{16}: rebase -i (start): checkout refs/remotes/origin/mastera585f1d HEAD@{17}: rebase: aborting7bc98a4 HEAD@{18}: rebase -i (start): checkout refs/remotes/origin/mastera585f1d HEAD@{19}: rebase -i (finish): returning to refs/heads/mastera585f1d HEAD@{20}: rebase -i (start): checkout 9f28970a585f1d HEAD@{21}: rebase -i (finish): returning to refs/heads/mastera585f1d HEAD@{22}: rebase -i (start): checkout refs/remotes/origin/mastera585f1d HEAD@{23}: rebase: abortingeaadebf HEAD@{24}: rebase -i (pick): Adding comments from Mullins consult - through rev chapter7bc98a4 HEAD@{25}: rebase -i (start): checkout refs/remotes/origin/mastera585f1d HEAD@{26}: commit: still dealing with shp bs4bef02c HEAD@{27}: commit: Removing shapefilescc061ac HEAD@{28}: commit: Adding comments from Mullins consult - through rev chapter21c5ab7 HEAD@{29}: commit: Adding comments from Mullins consult - through rev chapter9f28970 HEAD@{30}: commit: Hopefully .gitignore is now workinga2bdbae HEAD@{31}: commit: Adjusting gitignorec3e5128 HEAD@{32}: commit: Adjusting gitignore8f8b96e HEAD@{33}: commit: Adding gitignore to avoid tracking shapefiles0c14e14 HEAD@{34}: commit: Adding gitignore to avoid tracking shapefiles3b2d5e8 HEAD@{35}: commit: Adding many images 解决方案 The first thing to remember here is that git push pushes commits. If any files happen to be included, that's purely a matter of being needed for the commits that are being pushed.The second thing to remember is that when you do git push, your git and "their" git (a git command running on github, in this case) generally have a little talk with each other, of the form:"I have commit <SHA-1> I'd like to give you, and then I'd like you to set your branch master (or whatever other branch) to point to that SHA-1.""Well, I have <different SHA-1> for that branch. Tell me what SHA-1s I need to fill in any holes between what I have and what you have." (There's more to it than this, and it goes in a different order, but the essence is an exchange of who-has-what commit and other object IDs.)Once they know what IDs each other has, the sender packages up "whatever is needed": this is a series of commits (possibly empty) and any entities—mainly (but not quite limited to) files—that go with those commits, that the receiver also does not already have. In this case the sender is your git, the receiver is their git, and the package includes some large file(s).You decided you wanted not to send the large files. This means you must replace the commit(s) you're asking your git to send, with some new commit(s) you will ask your git to send. If the new commit(s) do not refer to the large files, then when your git goes to send the commits, their git will not ask for the files either, and your git won't send them.The Pro Git book has a section on "rewriting history" that covers this fairly well. What's missing (at least if you just read the one section, there are other sections that cover this) is a diagram of what a rebase really does.(Incidentally, your git repo will still contain the large files, and will continue to do so until all references to those files are gone, including the sort of ghost references that linger in git's "reflogs" after history-rewrite operations. It's these lingering ghosts that allow you to resurrect files if you make a mistake during the history rewrite. Reflog entries persist for 30 days by default, for these entries at least—"more active" reflog entries persist for 90 days by default—but unless you're doing something unusual you can normally just let them expire on their own.)The git rebase documentation has some diagrams, such as this one: A---B---C topic / D---E---F---G master[becoming] A'--B'--C' topic / D---E---F---G masterThe individual letters stand for commits, and the reason this has A' instead of A, and so on, after the rebase, is that rebase doesn't—can't—actually move a commit, it can only make a copy. The original commits are still in there, they just don't have a label like topic keeping them visible. If the copies are different—and they are—then they have a new, different SHA-1. It's the SHA-1s that really matter, at least during push (and fetch).In your case, what you want to do when rebasing is to make "deliberately flawed copies", where the originals have the large files, and the "flawed" copies don't. (In fact, of course, it's "having the large file" that is the flaw, so the not-quite-perfect-copy copies are the right ones, it's the originals that are wrong!)Interactive rebase has the additional ability to "squash" a new commit into an existing commit, i.e., to take the copy it's going to make and modify it based on the next commit in the sequence.The other big difference between what you want to do, and what is in the diagram above, is that you want the new commit(s) to start from the same point as the originals: H - I <-- master [in your repo] /... - G <-- origin/master [i.e., what's on github as master]Here commit H might be the flawed one with the extra file(s), and I might be the commit that removes the extra files. If you ask to push your master to github and have github set that as its master, your git and their git will chat and decide that github needs H and I and some files—including, because of H, the big ones.If you rewrite your own history so that in place of H and I you have one single new H'I' commit—let's just call this J for simplicity—then you'll have this diagram instead: H - I [abandoned ghosts] /... - G <-- origin/master [i.e., what's on github as master] \ J <-- masterNow you can have your git call up github's git and propose sending just J, which does not have the big files in it.Note that there are two keys to all of this:Commit G (as pointed-to by origin/master) does not have the big files, but is in both your repository and the repository on github. It's the shared starting point for the push: it's the first commit your side leaves out when pushing, because their side already has it.Commit J (and/or any other commits you will push) must also not have the big files. That way, when your git talks with their git, your git will decide that what it needs to send does not include the big files.In the end, it doesn't matter how many commits your side will send over in the push, what matters is what's in those specific commits. You can rewrite stuff that "only you have" as often (or rarely) as you like, to however you like it. Once you've successfully given those commits over to another repository, if you "rewrite" them to new slightly-different copies, the other repo still has the originals and other users may have gotten them as well (if that other repository is generally accessible).(You can still "rewrite history" and use a --force push to ask the other repo to discard some commit(s), including originals that you've decided are bad. There's nothing inherently wrong with this either, it's just that anyone collaborating with you may have picked up those "wrong originals" and they may be using them, so you're making more work for those people too.)One last note, on the fact that git rebase -i is showing an empty list: this suggests you've actually removed all the commits you had that they didn't. That is, instead of going from: H - I <-- master /... - G <-- origin/masterto: J <-- master /... - G <-- origin/masteryou've somehow simply discarded H and I entirely, so that your master points to commit G too.This could happen if you did a rebase -i and told git to squash I into H, and it did, and the result was exactly the same files as are in commit G. (For instance, if the only difference from G to H is "add big-file" and the only difference from H to I is "remove big-file", the combination of the two has no difference from G.) Git does allow an "empty" commit—a commit with author, message, etc., as usual, but with the same tree as the previous commit—but by default, rebase assumes you don't want that: it just strips out the canceled-out commits entirely.If you did have other commits that have vanished, those "ghost commits" I mentioned earlier are just what you need. To find them, look in the "reflogs":$ git reflogand:$ git reflog masterThese reflogs keep a history of where HEAD and master (or any other branch) have pointed over the last up-to-90-days: the raw SHA-1 IDs of both commits, whether they're regular commits that will stick around forever, or lingering ghost commits retained only by the reflog entries. 这篇关于混帐尝试推送不存在的文件...清除缓存后的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持！ 上岸，阿里云！