具有大文件的 Git 工作流程

Question

I know this has been asked and discussed earlier, but I couldn´t find the right workflow for this problem.

Let´s say I´m working on a new project that I want to push to GitHub. After a few commits and pushes that worked well, I continue coding and editing and at some point I add some big files larger than 100MB to my project (without knowing or keeping in mind that this will cause problems when I will try to push it in the next step).

So I do:

git add . 

and after that I do:

git commit -m 'some commit message'

and finally:

git push

And now I am in trouble, because I get the remote error: Large files detected.

So what are my options here to 1. keep my project changes and my added files alive and 2. exclude the big files files from future commits.

I have found the command to delete the last commit (where I added the big files among other things) with git revert … , but this is not want I want, because it also deletes all the work from my working directory.

Answer 1

For your immediate problem, you want to rebase/edit:

git rebase -i HEAD~1

Where "1" is the number of commits back your bigass commit is. For example, for 3 commits back, I might get an $EDITOR interface like:

pick d187a63 Some bigass file and other stuff
pick d1dff5c Use https for remote service
pick e8a29cd Add honeybadger

# Rebase e99b72e..c564a67 onto e99b72e (       3 TODO item(s))
#
# 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.

By manipulating the non-comment lines, git will apply corresponding manipulations to your commits. In your case, you want to change "pick" to "edit" for the bigass commit. Then you will be back on the command-line in a mid-rebase state where you can:

git rm bigass.file              # remove the file from the commit 
git commit good.file other.file # make additional commit(s) w/ just the stuff you want
git rebase --continue           # wrap up rebase

To wrap up, account for all the uncommitted files (by removal, exclusion or inclusion) and git rebase --continue .

NOTE: You can also ignore generated files locally without affecting .gitignore , using .git/info/exclude . You can use the same entries there that you would use in .gitignore , but they will never get pushed to remote or overwritten. Beware: this can make you crazy if you ignore something incorrectly or forget about what you are ignoring!

More broadly, if you do intend to version large files, you may be interested to amend your workflow to use git-lfs (Large File Storage), addressing this exact problem. It stores content hash/pointers in git proper and the massive binaries in a cloud datastore. It has support from Github and Microsoft VSO (including free unlimited storage), among others.

Answer 2

As I understand it, the last commit has a combination of changes plus one large file. If you revert that commit, that may make it look like the large file is gone, but its still present in the history. So if you pushed, you might still have a problem. If you want to remove the large file from your history but keep your other changes in that commit, you might do an interactive rebase of that last commit and edit it to remove the big file.

Answer 3

This achieves the same effect as Joe A's answer except its a lot simpler and in my view it's a lot safer for someone unfamiliar with the area.

git reset --soft HEAD~
This will undo the commit but leave all the things that would have been committed as staged.
Then git rm the files that shouldn't have been committed and then re-commit.
Now you should be able to push.

Note there is nothing technically wrong with Joe's answer and I have upvoted it; it's just overkill and overly complicated for such a simple problem. However if your commit chain included n>1 commits Joe's answer would be your best option. So this is more like a special case where you can do somethign safer since it was just your last operation that was problematic.