How to git pull while ignoring the local changes?

Question

As I am trying to pull some changes from origin/master, I am getting this error :

error: Your local changes to the following files would be overwritten by merge

because I made local changes. I don't want to commit these changes, so I suppose I should use git stash on my branch, then git pull origin master

My question is :

1. Will the pull simply ignore the changes and merge correctly
2. Can I still use my local changes after the pull + the ones merged without any additional step ?

Thank you !

PS : yes, I googled, I just want to make sure I understood correctly.

Solution 1

Here is how your repo evolves when all is applied :

1. Before you pull, with your local modifications :

    --*--*--*--*--*--*--A--B (<- some changes you did not commit yet)
          \             ^
           \            master: your latest local commit on master
            \
             *--*--C origin/master: the latest commit on the remote repo
   

2. after git stash :

                          B <- stash: git stored local changes in its stash
                         /         
    --*--*--*--*--*--*--A <- master: the files on your disk have been restored
          \                          to their state in "master"
           \            
            \
             *--*--C origin/master: the latest commit on the remote repo
   

3. after git pull :

                          B <- stash
                         /         
    --*--*--*--*--*--*--A--D <- master: merged remote branch in local branch
          \               /
           \             /   
            \           /
             *--*--C---/
                   ^ origin/master
   

git applies the action it usually does when pulling: merge the remote changes in your local branch.

4. after git stash apply :

                          B <- stash
                         /         
    --*--*--*--*--*--*--A--D--B' <- modifications stored in B (not committed yet)
          \               /
           \             /   
            \           /
             *--*--C----
                   ^ origin/master
   

git re-applies the modifications stored in the stash on top of the new leading commit

---

The caveats are :

• step 3. (git pull) may trigger some conflicts, which you will need to solve before actually reaching the state D in the diagram
• step 4. (git stash apply) may also trigger some conflicts, if your local changes (the ones stashed in B) actually interfere with some modification from origin/master.
  You will need to solve these before reaching B' in the diagram.

Solution 2

If you pull new code from server it will overwrite your local code.

If your changes are important you must commit them and then pull from server. And them you will be able to compare the changes and merge those properly.

do : git commit -m "Any message"then git pull And then ONLY IF NEEDED git will ask you for solving merge conflicts.

I strongly advice you to use any GUI Based git manager. It will simplify a lot your work.

If your changes are so minor that it does not deserve a commit, you can put your local changes in a temporary place and then bring it back. do the fallowing.:

1. stash your changes git stash . I will put all your local changes in a Temp place.

2. pull from server git pull. All your changes will be overwrite.

3. bring back your local changes from stash git stash pop. It will bring the local changes back.

Solution 3

Use those commands :

git stash  # stash you changes
git pull : # pull
git stash pop # re-get the stashed changes, not needed if you don't want to keep your changes

Solution 4

Logically, this should be a comment on all three (at the time I wrote this) of the answers that recommend the sequence:

git stash
git pull
git stash pop   # or "git stash apply" -- "pop" means "apply, then drop"

all of which are fine answers. But I need room to format things and write a lot. :-)

---

I don't want to commit these changes

Don't be afraid of committing! You can also commit, then un-commit. In fact, using git stash makes commits: they're just commits that are not on any branch. This can help somewhat with the second thing below. But the key here is to remember that your local branches are yours, to do with as you will.

---

Using git fetch—which is what git pull does first, before it does a second thing—has no effect on your branches, only on the so-called remote-tracking branches. These remote-tracking branches are your Git's way of remembering what it saw on that other Git at origin. That is, your origin/master, for instance, remembers what they have now. As they make changes in their Git, your origin/master gradually falls behind, but at any time, you can run git fetch and get "what they have now" and your origin/master is once again up to date. This has no effect on your own master.

After the fetch, you need to use some second thing—a second Git command—to incorporate "their" work into one or more of your branches. This second thing can be git merge or git rebase. If you run git pull you have implicitly chosen one of those two commands. I always argue that it is better to choose one explicitly, so that you know what you are doing here, but if you like, you can let git pull choose one. It will choose git merge by default. This means you get all of the complications of git merge and none of the complications of git rebase.

You probably don't want complications at all. This is kind of tough, because Git being Git, you get complications. Sometimes merge will fail. Sometimes rebase will fail. This is one of the reasons I argue you should pick one explicitly: when git pull fails, you need to know which second thing it is that git pull ran that failed!

I suspect you are avoiding commits because having your own commits makes it much more likely for git merge or git rebase to fail. This is true! This is also why git stash can help. But remmber, git stash is just making commits that aren't on your branches—and this means that if you avoid a failure here, at the first two steps that git pull runs, you are just moving the point of failure to when you un-stash with git stash pop or git stash apply!

---

The bottom line, as it were, is that no matter what you do, you will eventually run into a problem: you will have some change you have made that conflicts with some change someone else has made.

You will have to combine these changes. This combining is an action—a verb, as it were—that Git calls merging. This merge-as-a-verb, this action of merging, happens with both git merge and git rebase, and it also happens with git stash apply (which is the first half of git stash pop).

There is nothing wrong with doing this via git stash, but you will eventually have to learn how to do it. Once you know how to do it, you can also do it with git merge or with git rebase. To do merging in Git, you will want to use commits, whether those commits are those made by git stash, or by yourself running git commit. So don't be afraid to commit! You can put this off as long as you like, of course—and using git stash before pull can make this easier—but remember that git stash is making commits, and git pull is running merges!

View more solutions