Answers ( 3 )

  1. 2017-01-03 09:01

    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

  2. 2017-01-03 09:01

    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 head of 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.
    
  3. 2017-01-03 10:01

    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.

◀ Go back