git pull command basically fetches any update present on the remote repository but not yet present in local repository and merges the change. This command is basically combination of two commands git fetch; git merge FETCH_HEAD.

git pull commit diagram

default “git pull” command

Basically git pull fetches and replays changes from the remote master branch since it diverge from the local branch (i.e A) until its current commit (i.e E) on top of master. It records this result as a new commit. The above shown image displays how the commit history will look like after the commit. In day-to-day code development life cycle different team members sync their local repo with pull command and make unnecessary micro merge which pollutes the commit history.
git pull command commit history

“git pull” command commit history

But git pull --rebase command can avoid such micro-merge commit and helps to keep commit history clean. When this command is executed, it fetches all commits from remote master branch since it diverge from the local branch (i.e A) rebase the local commits by recomputing hashtag for local commits. As you can see in the below picture that D and E commits have become D’ and E’ after the rebase.
git pull --rebase command

“git pull –rebase” command

The commit history looks linear and clean. It doesn’t contain any unnecessary merge commit.
git pull --rebase command commit history

git pull –rebase command commit history

If the history is already published then ‘git pull –rebase’ command should not be used. Because it rewrites history and will mess-out the future merge/rebase.

You can obviate --rebase option by configuring the git for particular branch.

/>  git config branch.master.rebase true 

If can also put this configuration at global level by executing this git configuration command.

/> git config --global branch.autosetuprebase always

Hope this blog helped you in some way. If you like this blog then please share it. You can also leave your comment below.

Related posts

  1. Handy git commands

2 comments untill now

  1. rebase – is a not merge, essentially it is a patch operation that can made a lot of possible dangerous situation if you use patch for different file revision than it was made. try to use instead git “merge squash”

  2. @Yury, I agree with you that rebase is dangerous and it should be used with care.
    I have a question here regarding “git merge squash” wouldn’t this command merge the different commits to one. So eventually you will loose your commits’ history. Correct me if the above question/statement is wrong.

Add your comment now