Monday, June 25, 2012

git pull vs git pull --rebase

1) Let us suppose we are working on branch B1.
2) I have taken the checkout and start working on my code (let say C0_
3) I have made all changes , make commit (C1) and ready to push to branch B1
4) push : git push origin branch-name
then i got output as : branch not up to date , remote branch is fast forward by n commits. [It means in time between I have taken last checkout and push, some one has pushed changes into branch so the branch is not updated wr.t to remote branch]
5) Now i have to update my branch.
I have two choices :
a)Using git pull
b)Using git pull --rebase

Lets talk about second one :
git pull --rebase :
When i executed this :
It put my commit [which I want to push] at top.
For Ex :

Before pull --rebase i have :

C1[my local commit]
|
C0 [Last commit to which i have updated]

Now after git pull --rebase gitk shows :

C1[My local commit]
|
C2[New commits added between last checkout and my latest local commit]
|
C0[Last commit to which i have updated, before running git pull --rebase]

So : In short git pull --rebase, makes every history in linear chain and always re base the commits [i.e changes bases]

Now lets focus on git pull :

The difference is it will not try to rebase your commits.

After git pull

-C2[New commits added between my last checkout and latest commit]
| |
| C1[My local commit]
| |
C0[Last commit to which i have updated, before running git pull --rebase]


 This will create a loop around the commits and it is also hard to read the commit histories

 So in short i prefer git pull --rebase instead of git pull

Note :
pull [with or without rebase] do not conflict with local commits









No comments:

Post a Comment