So you want to git force pull
For the Googlers: there’s no such thing as `git force pull` -- instead, you want to run these two commands:
Together, these commands will discard your local changes (saving them for later) and replace them with the latest commit from your remote branch. Good luck!
Git stash it first
Now, for the curious: let’s pretend both you and Bob are separately working on a super-high priority bugfix at the same time. You’re in a competition, and the loser has to buy drinks for the team. You’re typing furiously at your keyboard and making good time, when suddenly John bursts through the door, announcing that Bob fixed the bug and pushed his changes to remote already (in record time, no less).
Crumbs, you think, and decide to pull down his code in order to figure out what the fix was. `git pull` gives you some gobbledegook error, so you try with the `--force` flag, thinking you’ll just easily override your local changes:
Unfortunately, that just gets you this lovely gem:
Despite your forceful statement, Git will blatantly refuse to override changes to your local filesystem.
As I said at the beginning of this article, what you really need to do is first stash or even throw away your current changes before pulling, like this:
After you run these commands, you’ll see that your local changes have been discarded, and the remote changes living on the server have been pulled down and applied to your working tree (the files on your hard drive). All is well! Except now you have to buy drinks for the team.
But why is it that you have to explicitly tell Git to throw away your local changes before you can pull? And why use `stash`? This article will explain the behavior of these two commands and suggest a couple of alternatives. As you’ll see, with Git, there are usually several ways to skin the cat!
How git stash works
Put simply, git stash stores your current, uncommitted changes in a place outside of your working tree, leaving you with a clean slate to start a new commit or pull changes down.
You can have more than one stash at a time, too -- if you run git stash a second time, with other changes, those changes will be stored in a separate stash. Then, if you want to see how many stashes you have, you can run git stash list.
If you want to clear your list of stashed changes, you can always run git clear stash. And if you want to bring back any stashed code, you can git stash pop it back into existence.
Why is stash recommended?
So why is `git stash` the best way to get back to a clean working directory?
One, there’s always a chance that you’ll want to retrieve your work again. With the power of a version control system like Git at your fingertips, there’s almost never a good reason to completely delete code. It’s easy to store and easy to get it back by just typing git stash apply.
Two, `stash` is actually the simplest way to get back to a clean working directory. It will store all of the files, including the ones in staging, in just one short command with no need for additional flags or arguments. Easy to remember, easy to type.
Pro tip: The stash files are stored in `.git/refs/stash`, and you can view all of your stashed changes by running the command git stash list.
What does `git pull` actually do?
The command git pull is actually a shortcut command that encompasses two operations: git fetch and git merge. The fetch grabs the latest commits from the remote repository, and the merge is what actually applies those commits to your current commit.
Once you understand this, it starts to become clearer why you can’t simply overwrite local changes with `git pull` -- Git just isn’t architectured that way. Trying to do so will produce the same result as trying to merge a branch in while you have local changes: an error.
Pro tip: Incidentally, the best way to do that is git stash, git merge my-branch, and then git stash pop to reintegrate your local changes.