Say the remote is origin
and the branch is master
, and say you already have master
checked out, might try the following:
git fetch origin git reset --hard origin/master
This basically just takes the current branch and points it to the HEAD
of the remote branch.
WARNING: As stated in the comments, this will throw away your local changes and overwrite with whatever is on the origin.
Or you can use the plumbing commands to do essentially the same:
git fetch <remote> git update-ref refs/heads/<branch> $(git rev-parse <remote>/<branch>) git reset --hard
EDIT: I’d like to briefly explain why this works.
The .git
folder can hold the commits for any number of repositories. Since the commit hash is actually a verification method for the contents of the commit, and not just a randomly generated value, it is used to match commit sets between repositories.
A branch is just a named pointer to a given hash. Here’s an example set:
$ find .git/refs -type f .git/refs/tags/v3.8 .git/refs/heads/master .git/refs/remotes/origin/HEAD .git/refs/remotes/origin/master
Each of these files contains a hash pointing to a commit:
$ cat .git/refs/remotes/origin/master d895cb1af15c04c522a25c79cc429076987c089b
These are all for the internal git storage mechanism, and work independently of the working directory. By doing the following:
git reset --hard origin/master
git will point the current branch at the same hash value that origin/master points to. Then it forcefully changes the working directory to match the file structure/contents at that hash.
To see this at work go ahead and try out the following:
git checkout -b test-branch # see current commit and diff by the following git show HEAD # now point to another location git reset --hard <remote>/<branch> # see the changes again git show HEAD