Git – Can’t push to GitHub because of large file which I already deleted

Find the last commit that affected the given path. As the file isn't in the HEAD commit, that previous commit must have deleted it.

git rev-list -n 1 HEAD -- <file_path>

Then checkout the version at the commit before, using the caret (^) symbol:

git checkout <deleting_commit>^ -- <file_path>

Or in one command, if $file is the file in question.

git checkout $(git rev-list -n 1 HEAD -- "$file")^ -- "$file"

If you are using zsh and have the EXTENDED_GLOB option enabled, the caret symbol won't work. You can use ~1 instead.

git checkout $(git rev-list -n 1 HEAD -- "$file")~1 -- "$file"

Note: the git1.7.10 (April 2012) actually allows you to clone only one branch:

# clone only the remote primary HEAD (default: origin/master)
git clone <url> --single-branch

# as in:
git clone <url> --branch <branch> --single-branch [<folder>]

(<url> is the URL if the remote repository, and does not reference itself the branch cloned)

You can see it in t5500-fetch-pack.sh:

test_expect_success 'single branch clone' '
  git clone --single-branch "file://$(pwd)/." singlebranch
'

Tobu comments that:

This is implicit when doing a shallow clone.
This makes git clone --depth 1 the easiest way to save bandwidth.

And since Git 1.9.0 (February 2014), shallow clones support data transfer (push/pull), so that option is even more useful now.
See more at "Is git clone --depth 1 (shallow clone) more useful than it makes out?".

"Undoing" a shallow clone is detailed at "Convert shallow clone to full clone" (git 1.8.3+)

# unshallow the current branch
git fetch --unshallow

# for getting back all the branches (see Peter Cordes' comment)
git config remote.origin.fetch refs/heads/*:refs/remotes/origin/*
git fetch --unshallow

As Chris comments:

the magic line for getting missing branches to reverse --single-branch is (git v2.1.4):

git config remote.origin.fetch +refs/heads/*:refs/remotes/origin/*
git fetch --unshallow  

With Git 2.26 (Q1 2020), "git clone --recurse-submodules --single-branch" now uses the same single-branch option when cloning the submodules.

See commit 132f600, commit 4731957 (21 Feb 2020) by Emily Shaffer (nasamuffin).
^{(Merged by Junio C Hamano -- gitster -- in commit b22db26, 05 Mar 2020)}

clone: pass --single-branch during --recurse-submodules

^{Signed-off-by: Emily Shaffer
Acked-by: Jeff King}

Previously, performing "git clone --recurse-submodules --single-branch" resulted in submodules cloning all branches even though the superproject cloned only one branch.

Pipe --single-branch through the submodule helper framework to make it to 'clone' later on.