Can I use git pull --rebase instead of "git stash git pull git stash pop"?

Question

What is the difference between

git pull --rebase

and

git stash
git pull
git stash pop

Answer 1

git pull: you actually issuing git fetch + git merge commands, which will result with an extra commit and ugly merge bubbles in your commit log.

git pull --rebase: to keep the repository clean, your commits always on top of the tree until you push them to a remote server. The command will apply all your yet-to-be-pushed commits on top of the remote tree commits allowing your commits to be straight in a row and without branches

Answer 2

I would suggest you create an experimental repo and try the commands out. Experimenting by yourself makes learning easier.

You will notice that the command sequence git stash; git pull; git stash pop will move uncommitted changes to the updated head of the master branch. (It will also do a normal merge, so committed changes will be merged, not rebased, assuming default gitconfig)

However, git pull -rebase will move changes which have already been committed to the updated head of the master branch. If you try running this command with a dirty work tree, you will see the error message:

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

Answer 3

The simple answer to your question in the subject is "no".

The difference between git pull --rebase and git pull is, that the first does a fetch + rebase, the second a fetch + merge, except you have a non-default git config that tells git pull to do a rebase instead of a merge. In that case the two commands would be identical.

The difference between those two commands does not influence in any way the need to stash and unstash uncommitted changes. Both need this if you have a dirty worktree or they will error out, telling you to commit or stash your changes.

Answer 4

I know this is a year old post, but...

git pull --rebase

~ vs ~

git stash /git pull /git stash pop

git pull --rebase is sort of a hybrid - if you will - between the two. It will allow you to keep your commits, and pull the most recently committed (pushed) files from your central repo. It's kinda like time travel, dude.. explosion noise

But to answer the question.... Git stash holds on to uncommitted changes, then puts 'em back after the pull is finished.

So - if you're not completely done with something, but need the newest files on the central repo, you would:

git stash git pull git stash pop

However, say you have finished something, and committed it - but your coworker Timmy who never tells anyone shit, has committed files and pushed them to the main(central) repo, you should get his stuff first, THEN add your commits to the stack, and push'em..

If you have commits, and haven't pushed your changes to the main(central) repo, and have to obtain the new files on the central repo because another dev has since committed and pushed their files - you would use:

git pull --rebase

Its like when you make a hamburger, but forgot to try the homemade cheese your buddy wants you to try, so here he comes with your slice and you have to take your top bun off to apply this cheese, and then put the bun back on - boom bang bing. cheeseburger.

Answer 5

To answer the question in the title: No, but you can use this to achieve what you want in one command:

git pull --rebase --autostash

More info: https://cscheng.info/2017/01/26/git-tip-autostash-with-git-pull-rebase.html