您已经用veyr通用词讲了所有内容，所以我主要是猜测.

You've said everything in veyr general words, so I'll be mostly guessing.

首先，如果您在添加和提交文件夹中的大文件后立即意识到了问题，并且没有再进行任何提交，则进行了 git commit --amend 是你的朋友. git rm 从该文件夹中删除该文件，使用--amend选项提交该删除操作，然后将大物件放入一个文件夹进行提交更正/重写并且大文件将被永久地"从该提交中删除.坏消息是-amend 仅适用于最新的提交.您不能-修改任何最近的较旧的提交:

First, if you realized the problem right after adding&committing the large file in a folder, and if you did not make any more commits then git commit --amend is your friend. git rm that file from that folder, commit that deletion with --amend option and the commit-with-large-thing-in-a-folder will get corrected/rewritten and the large file will be "permanently" removed from that commit. The bad news is that --amend works only on the very latest commit. You cannot --amend any older commit that the most-recent:

git add folder
git commit            ## oops!!
git rm folder\hugefile.zip
git commit --amend    ## uff

否则，如果您在该次失败之后做出了一些提交，请复查那些提交.如果所有这些值很小或没有，或者很容易重做，那么***的方法是 git reset 来全部删除/撤消它们，然后--修改与上面的大文件一起提交，然后重做多余的提交.

Otherwise, if you made some commits after that bad one, review those commits. If all of them have low or no value or are easily redoable, then the best way would be to git reset to trash/undo them all, and then --amending the commit with big file as above, and then redoing the extra commits.

git add folder
git commit -m AAA            ## oops, but I didn't notice yet
git add foo\bar
git commit -m BBB
git rm baz\boom
git commit -m CCC
# uh-oh, I just noticed the big file..
git log       # find the commit hash of 'AAA'
git reset --hard  THATCOMMITHASH
git rm folder\hugefile.zip
git commit --amend          # uff.. but BBB and CCC evaporated!
git add foo\bar
git commit -m BBB           # redo BBB
git rm baz\boom
git commit -m CCC           # redo CCC

((如果您很聪明，您也可以从日志中记录BBB和CCC的提交哈希，并且无需手动重做它们，即使重置后也可以 git cherrypick )，但我现在不会再对此进行研究了

(if you're smart, you'd write down the commit hashes of BBB and CCC from the log too, and instead of redoing them manually, you could also git cherrypick them even after reset, but I won't delve into that now)

当然，这对于大文件是不可行的.当然，如果有的话，执行 git reset --hard 也会丢弃所有未提交的本地更改.

Of course, that's infeasible for large files. And of course doing git reset --hard will trash all your uncomitted local changes, too, if you had any.

如果以上两个都不适合您，那么，您将需要更加努力.例如，如果您有本地更改，则不想丢失，先提交或存放它们，然后按照上面的第一种或第二种方法进行操作.如果您有很多提交，并且不能或不想手动重做，则可以使用rebase.

If neither of those above are OK for you, then, well, you will need to try harder. For example, if you have local changes you dont want to lose, commit or stash them first, then do the first or second way as above. If you have many commits and can't or don't want to redo them manually, you can play with rebase.

重新设置编辑"(重写)提交的历史记录，并具有以下功能:

Rebase 'edits' (rewrites) the history of commits and has the power of:

• 选择或忽略提交
• 更改提交顺序
• 将提交压缩/合并为一个，类似于-amend

因此，要使用rebase:

So, to use rebase:

• 提交所有本地更改，请不要删除大文件
• 删除大文件，将其作为单独的提交进行提交
• 运行 git rebase -i HASH_OF_ONE_COMMIT_BEFORE_HUGE_FILE_ADDED ，这将运行交互式rebase"并应使用"rebase plan"打开文本编辑器
• 在基础计划中，找到添加文件的提交(应该在列表的第一位)，找到删除文件的提交(应该在列表的最后)
• 在基础计划中，剪切并粘贴删除文件的提交的 pick 行，并在添加文件的提交之后立即将其移动
• 将提交的模式( pick )更改为 fixup
• 保存计划，让基础继续

• commit all local changes, DONT remove the huge file yet
• remove the huge file, commit that as separate commit
• run git rebase -i HASH_OF_ONE_COMMIT_BEFORE_HUGE_FILE_ADDED, this will run "interactive rebase" and should open a text editor with "rebase plan"
• in the rebase plan, find the commit that adds the file (should be first on the list), find the commit that removes the file (should be last on the list)
• in the rebase plan, cut&paste the pick line of the commit-that-deletes-the-file and move it right after the commit that added the file
• change the mode (pick) of that commit into fixup
• save the plan, let rebase continue

这将有效地及时移动"删除文件的提交，使其恰好在添加之后，然后将添加和删除合并为一个提交(带有来自添加的消息).实际上，就像您记得当时要进行修改一样.但是，实际上，这将重写历史记录(顺便说一句，amend也会这样做)，因此，如果您曾经设法以某种方式推送了任何原始的未重写的提交，那么其他人在这样做之后可能会生您的气.但这不是事实，因为您在提交大文件后无法进行推送，对吧?

This will effectively "move in time" the file-deleting commit to be just-after the addition and then will merge addition and deletion into one commit (with message from addition). Effectively, it'd be just as if you remembered to --amend that back then. However, in fact this will rewrite history (btw. amend also does that), so if you have ever somehow managed to push any of the original-not-rewritten commits then other people may be angry at you after doing so. But that shouldn't be the case since you were unable to push since committing the large file, right?