Error: Cannot pull with rebase: You have unstaged changes

Question

I have started collaborating with a few friends on a project & they use the heroku git repository.

I cloned the repository a few days ago and they have since made some changes so I am trying to get the latest updates

I ran the git pull --rebase command as stated here(Is this the right way to do it?): https://devcenter.heroku.com/articles/sharing#merging-code-changes

I get the following error:

$ git pull --rebase
Cannot pull with rebase: You have unstaged changes.
Please commit or stash them.

My guess is that I messed around with the code and now it wants me to either commit or discard(is that what does stash means?) the changes. Is this what is happening? If this is the case I would like to discard any changes I might have made and just get the updated code from the git repository.

Any idea of what I can do?

score 281 · Answer 1 · answered Apr 06 '17 at 18:20

281

If you want to keep your working changes while performing a rebase, you can use --autostash. From the documentation:

Before starting rebase, stash local modifications away (see git-stash[1]) if needed, and apply the stash when done.

For example:

git pull --rebase --autostash

answered Apr 06 '17 at 18:20

mkobit

43,979
12
156
150

22

This is the modern answer. – adl Feb 28 '18 at 09:28
70

If you want autostash to be the default behavior you can set `git config --global rebase.autoStash true` Then you don't need to pass the switch. – Zoredache Sep 18 '18 at 22:24
1

THIS, what I was looking for! (note that the command line switch is available from git 2.9, but the option `rebase.autostash` is available from 2.6). – jjmontes Oct 04 '18 at 20:03
This works great for [`git rebase --interactive`](https://stackoverflow.com/questions/1884474/change-old-commit-message-on-git/45302710#45302710) too! – Dan Dascalescu Feb 24 '19 at 04:16
17

Why isn't this the default? – Nick May 27 '19 at 01:13
Thank you! I needed the --autostash flag for `git rebase master`! – Dan Korn Sep 04 '19 at 01:09
This was the default, until like this week. No idea why they changed it. – Andrew Koster Jun 18 '20 at 23:57
What is funny(?) is that this is like subversion has worked since like forever. The defaults in git are just out of contact with reality. – osexpert Mar 24 '21 at 20:19

score 240 · Accepted Answer · answered May 07 '14 at 12:20

240

Do git status, this will show you what files have changed. Since you stated that you don't want to keep the changes you can do git checkout -- <file name> or git reset --hard to get rid of the changes.

For the most part, git will tell you what to do about changes. For example, your error message said to git stash your changes. This would be if you wanted to keep them. After pulling, you would then do git stash pop and your changes would be reapplied.

git status also has how to get rid of changes depending on if the file is staged for commit or not.

answered May 07 '14 at 12:20

Schleis

41,516
7
68
87

1

This seemed to have work but now I am facing another error(started a new questions to not confuse future vistors): http://stackoverflow.com/questions/23518247/error-git-pull-rebase-permission-denied-publickey-fatal-could-not-read-f – user3597950 May 07 '14 at 12:47
I'm literally having this every single time, just recently. Before, pulling files that doesn't affect your current changes is fine but now, it requires everything you've change to stash. I cannot even push, I'm forced to use `git push -f` – Karma Blackshaw Jun 10 '20 at 03:19
1

@KarmaBlackshaw You shouldn't be need to force push. If you have to do a force push, that means that your local history and the remote history are different and that is a different question than what this answer covers. – Schleis Jun 10 '20 at 13:27
It is indeed a different that what the scope of this question provides. But I did found a way by deleting the current branch and making a new branch from develop. I guess it was my branch that had some things configured wrongfully. – Karma Blackshaw Jun 10 '20 at 16:04
Use "git status" to check your local workspace. And use git use "git checkout -- ..." to discard changes in working directory. Also, "git pull --rebase" will OK. – Vittore Marcas Jan 01 '22 at 23:40

Kostas Rousis · Answer 3 · 2014-08-28T08:06:02.980

64

Pulling with rebase is a good practice in general.

However you cannot do that if your index is not clean, i.e. you have made changes that have not been committed.

You can do this to work around, assuming you want to keep your changes:

stash your changes with: git stash
pull from master with rebase
reapply the changes you stashed in (1) with: git stash apply stash@{0} or the simpler git stash pop

edited Aug 28 '14 at 08:06

answered May 07 '14 at 12:20

Kostas Rousis

5,918
1
33
38

1

This seemed to have work but now I am facing another error(started a new questions to not confuse future vistors): http://stackoverflow.com/questions/23518247/error-git-pull-rebase-permission-denied-publickey-fatal-could-not-read-f – user3597950 May 07 '14 at 12:48
6

@nehemiahjacob You can also `git stash pop` to apply the most recently stashed changes and to avoid memorizing the longer `apply stash@{0}`. – Kostas Rousis Aug 28 '14 at 08:05
I have to do this all the time. Any easier way? – Alper Feb 04 '16 at 13:23
@alper usually you work on another (feature) branch. In my experience, I only fetch and rebase against master after I have committed my work, so there's no need to stash/pop. If you find yourself though doing that a lot during your development workflow, you can always make an alias in your `.bashrc` (or whatever you use): `alias stashpull='git stash; git pull; git stash pop'` – Kostas Rousis Feb 04 '16 at 14:08
@KostasRousis I have that exact alias, lol. I call it 'sppgit' – luizfls Mar 10 '20 at 14:34
Thanks for this. I never bothered to learn about git stash and always just manually committed any changes or put them into a different branch when I wanted to pull. – thomasrutter Dec 04 '22 at 03:29

score 60 · Answer 4 · answered Mar 26 '20 at 22:40

60

If you want to automatically stash your changes and unstash them for every rebase, you can do this:

git config --global rebase.autoStash true

answered Mar 26 '20 at 22:40

agirault

2,509
20
24

5

This is the only answer that makes the newest version of Git work the same way Git has always worked in the past. Why make people add `--autostash` when it can just be... automatic? – Andrew Koster Jun 18 '20 at 23:58
This almost makes git usable. Closer to the sane way that mercurial works anyway. – swpalmer Aug 26 '23 at 23:07

score 45 · Answer 5 · edited Mar 15 '21 at 23:00

45

First start with a git status

See if you have any pending changes. To discard them, run

note that you will lose your changes by running this

git reset --hard

edited Mar 15 '21 at 23:00

ahmadali shafiee

4,350
12
56
91

answered May 07 '14 at 12:20

Igal S.

13,146
5
30
48

This seemed to have work but now I am facing another error(started a new questions to not confuse future vistors): http://stackoverflow.com/questions/23518247/error-git-pull-rebase-permission-denied-publickey-fatal-could-not-read-f – user3597950 May 07 '14 at 12:47
I still get an error: **fatal: Not possible to fast-forward, aborting.** – IgorGanapolsky Sep 14 '22 at 16:51

score 23 · Answer 6 · answered Nov 09 '17 at 15:14

23

This works for me:

git fetch
git rebase --autostash FETCH_HEAD

answered Nov 09 '17 at 15:14

CppChase

901
12
25

3

Ah autostash, that saves me an extra two commands. This should be the correct answer IMO. – Erik Berkun-Drevnig Nov 23 '17 at 19:29
1

You can also set it as default in your global git config, see [here](https://stackoverflow.com/a/60877307/3783833) – agirault Sep 21 '20 at 16:58

score 11 · Answer 7 · answered Jul 23 '14 at 20:35

You can always do

git fetch && git merge --ff-only origin/master

and you will either get (a) no change if you have uncommitted changes that conflict with upstream changes or (b) the same effect as stash/pull/apply: a rebase to put you on the latest changes from HEAD and your uncommitted changes left as is.

score 7 · Answer 8 · edited Jul 18 '17 at 04:02

When the unstaged change is because git is attempting to fix eol conventions on a file (as is always my case), no amount of stashing or checking-out or resetting will make it go away.

However, if the intent is really to rebase and ignore unstaged changed, then what I do is delete the branch locally then check it out again.

git checkout -f anyotherbranchthanthisone
git branch -D thebranchineedtorebase
git checkout thebranchineedtorebase

Voila! It hasn't failed me yet.

score 0 · Answer 9 · answered Oct 12 '20 at 13:46

0

Follow the below steps

From feature/branch (enter the below command)

git checkout master

git pull

git checkout feature/branchname

git merge master

answered Oct 12 '20 at 13:46

Thiru

25
1
8

score 0 · Answer 10 · answered Oct 22 '21 at 08:17

0

there you just need to restore the unstagged changes with this command below

for my case i had errors in yarn file for your case it can be another file

git restore --staged yarn.lock

answered Oct 22 '21 at 08:17

Bukenya KizzaRoland

721
1
7
13

score 0 · Answer 11 · answered Feb 20 '23 at 11:27

This is because you made some changes on your workspace, but you do not commit

that changed codes into local repository via

git add/rm <file> && git commit -m "Add/Delete file."

Just use git status to check which files have been changed, as you say

I would like to discard any changes I might have made and just get the updated code from the git repository.

I just recommend you to delete your older cloned repository, then clone the latest updates if that works for you.

Or, just use git reset --hard && git pull --no-rebase && git push if this works for you.

Error: Cannot pull with rebase: You have unstaged changes

11 Answers11

Linked

Related