What is the difference between git pull and git reset --hard origin/?

Question

I find the latter to be faster than the first, so I usually do that after git fetch whenever I need to sync my local branch with the remote. What is the difference?

`git pull` fetches from remote repositories, `git reset` deals with the local tree. How are they even comparable? — zerkms, Mar 27 '17 at 03:05
if your local branch differs from remote, `git pull` does the merge. `git fetch` with `git reset --hard` only checkouts it. — ymonad, Mar 27 '17 at 03:05
As a *very* loose analogy, think of `git pull` (which is `git fetch` followed by `git merge`) as: move me to a new address, taking all my possessions. Think of `git fetch` followed by `git reset --hard` as: burn all my possessions, then set me up at the new address. Since the houses come furnished, if you have no possessions of your own, the result is the same. But if you *do*, well... — torek, Mar 27 '17 at 03:40
@zerkms Sun and Moon are totally different things, but they are comparable in the sense that they give light to us. — technophyle, Oct 16 '17 at 18:31
@technophyle I think you need to read what `git reset` and `git fetch` do. Or answers. — zerkms, Oct 16 '17 at 18:59
@technophyle if you still think `git reset` and `git fetch` have anything in common - you're not understanding it well. — zerkms, Oct 17 '17 at 03:31
@zerkms man, read the question again. I'm not asking if `git reset` and `git fetch` have something in common. I'm asking about two specific actions. — technophyle, Oct 17 '17 at 17:42
To rephrase my question - what is the difference between `git pull` and `git fetch -> git reset --hard HEAD`, because the result is the same for the working copy? (of course, when there is no unstaged changes, and there is no fork) And I think this question is perfectly valid. — technophyle, Oct 17 '17 at 17:45
@technophyle the question is "What is the difference between git pull and git reset --hard origin/?". I copied it exactly. And the answer is - `git pull` and `git reset` have nothing in common. "because the result is the same for the working copy?" --- the result is totally not the same. I can easily make up repositories that would produce dramatically different results for both commands. — zerkms, Oct 17 '17 at 19:46
I totally do. `git pull` makes no sense after `git fetch` either. — zerkms, Oct 18 '17 at 03:06
@zerkms I recommend you to read the question and the answers and our conversation history before making assumptions. All the voters wouldn't be that stupid. — technophyle, Nov 29 '18 at 09:49

score 52 · Accepted Answer · answered Mar 27 '17 at 03:06

52

The following commands:

git fetch
git reset --hard origin/<branch>

will discard all local changes.

Where as:

git pull

Which is exactly the same as:

git fetch
git merge origin/<branch>

will attempt to preserve local changes.

answered Mar 27 '17 at 03:06

Penguin Brian

1,991
14
25

Sajib Khan · Answer 2 · 2019-07-04T03:29:09.773

6

$ git pull                        
# takes the latest changes of origin/branch (exists both local & remote changes)

$ git reset --hard origin/branch  
# replace your local with origin's branch history (discard local changes)

Example: Say, we have two commits in local A, B and remote has two commits A, C. Now if you pull then your local contains A, B, C unlike if reset then your local will have A, C not B.

edited Jul 04 '19 at 03:29

answered Mar 27 '17 at 03:05

Sajib Khan

22,878
9
63
73

score 2 · Answer 3 · answered Mar 28 '17 at 05:32

These two commands mostly used for different situations.

git pull pull (fetch & merge) changes from remote to local, especially other push commits to remote and you want these commit apply on your local branch.

git reset --hard origin/branch is force to make your local branch point to the commit where origin/branch is pointing to. It’s usually for the situation you want to abandon the local changes you made and keep the local branch as remote status.

score 0 · Answer 4 · edited Feb 26 '19 at 20:00

They are completely different in what they do:

git pull: Incorporates changes from a remote repository into the current branch. In its default mode, git pull is shorthand for git fetch followed by git merge FETCH_HEAD.

With git reset --hard origin/branch Git will:

Make your current branch (typically master) back to point at <SOME-COMMIT>.
Then make the files in your working tree and the index ("staging area") the same as the versions committed in <SOME-COMMIT>.

Note: it's always worth noting that git reset --hard is a potentially dangerous command, since it throws away all your uncommitted changes. For safety, you should always check that the output of git status is clean (that is, empty) before using it.

hurturk · Answer 5 · 2017-03-27T03:30:51.720

The way you are getting a source update is more important than your performance concern. You need to utilize them for specific cases. I can provide you two examples:

git reset --hard ... can be used for updating code in production if you often find yourself modifying production code for debugging. That usually happens on early stage of a project deployment with lazy thoughts.
git pull is most accepted way of getting new commits and it usually makes sense you won't have huge local changes. If your commit periods are longer with more people on same branch, you may eventually have a gut feeling to do git pull --rebase or fetch first then compare.

Git can be explicit for very specific needs of your development style, you can discover them on the road. Performance shouldn't be concern at all once you are happy your work is safe.

What is the difference between git pull and git reset --hard origin/?

5 Answers5