So if I'm using branches that are remote (tracked) branches, and I want to get the lastest, I'm still unclear if I should be doing git pull or git rebase. I thought I had read that doing git rebase when working on a branch with other users, it can screw them up when they pull or rebase. Is that true? Should we all be using git pull?
Asked
Active
Viewed 1.5k times
33
lucapette
- 20,564
- 6
- 65
- 59
Cameron Booth
- 6,882
- 5
- 28
- 22
5 Answers
52
Git pull is a combination of 2 commands
- git fetch (syncs your local repo with the newest stuff on the remote)
- git merge (merges the changes from the distant branch, if any, into your local tracking branch)
git rebase is only a rough equivalent to git merge. It doesn't fetch anything remotely. In fact it doesn't do a proper merge either, it replays the commits of the branch you're standing on after the new commits from a second branch.
Its purpose is mainly to let you have a cleaner history. It doesn't take many merges by many people before the past history in gitk gets terribly spaghetti-like.
The best graphical explanation can be seen in the first 2 graphics here. But let me explain here with an example.
I have 2 branches: master and mybranch. When standing on mybranch I can run
git rebase master
and I'll get anything new in master inserted before my most recent commits in mybranch. This is perfect, because if I now merge or rebase the stuff from mybranch in master, my new commits are added linearly right after the most recent commits.
The problem you refer to happens if I rebase in the "wrong" direction. If I just got the most recent master (with new changes) and from master I rebase like this (before syncing my branch):
git rebase mybranch
Now what I just did is that I inserted my new changes somewhere in master's past. The main line of commits has changed. And due to the way git works with commit ids, all the commits (from master) that were just replayed over my new changes have new ids.
Well, it's a bit hard to explain just in words... Hope this makes a bit of sense :-)
Anyway, my own workflow is this:
- 'git pull' new changes from remote
- switch to mybranch
- 'git rebase master' to bring master's new changes in my commit history
- switch back to master
- 'git merge mybranch', which only fast-forwards when everything in master is also in mybranch (thus avoiding the commit reordering problem on a public branch)
- 'git push'
One last word. I strongly recommend using rebase when the differences are trivial (e.g. people working on different files or at least different lines). It has the gotcha I tried to explain just up there, but it makes for a much cleaner history.
As soon as there may be significant conflicts (e.g. a coworker has renamed something in a bunch of files), I strongly recommend merge. In this case, you'll be asked to resolve the conflict and then commit the resolution. On the plus side, a merge is much easier to resolve when there are conflicts. The down side is that your history may become hard to follow if a lot of people do merges all the time :-)
Good luck!
-
1It seems to me that you should have said: 'git _merge_ mybranch', which only fast-forwards when everything in master is also in mybranch (thus avoiding the commit reordering problem on a public branch) – Bruno Bronosky Oct 21 '10 at 17:52
-
'git rebase mybranch' should definitely read 'git merge mybranch'. – James H Dec 18 '10 at 04:15
10
Git rebase is a re-write of history. You should never do this on branches that are "public" (i.e., branches that you share with others). If someone clones your branch and then you rebase that branch -- then they can no longer pull/merge changes from your branch -- they'll have to throw their old one away and re-pull.
This article on packaging software with git is a very worthwhile read. It's more about managing software distributions but it's quite technical and talks about how branches can be used/managed/shared. They talk about when to rebase and when to pull and what the various consequences of each are.
In short, they both have their place but you need to really grok the difference.
Pat Notz
- 208,672
- 30
- 90
- 92
-
Is this true, @Pat? In the case of a pull --rebase, aren't you just re-ordering your local commits to be on top of what you pulled from? Since those were local commits, and not published yet, how will they break someone who tries to pull after I `pull --rebase`'ed? – Gabe Hollombe Apr 07 '10 at 05:28
-
1The problem is if someone else pulls from a branch that you then rebase. It's fine if I pull from `A` into `local` then rebase `local`, and someone else pulls from `A`. It's not fine if I pull from `A`, someone else pulls from `local`, then I rebase `local`. – Cameron Skinner Oct 26 '10 at 22:30
-
1
6
git pull does a merge if you've got commits that aren't in the remote branch. git rebase rewrites any existing commits you have to be relative to the tip of the remote branch. They're similar in that they can both cause conflicts, but I think using git rebase if you can allows for smoother collaboration. During the rebase operation you can refine your commits so they look like they were newly applied to the latest revision of the remote branch. A merge is perhaps more appropriate for longer development cycles on a branch that have more history.
Like most other things in git, there is a lot of overlapping functionality to accommodate different styles of working.
Greg Hewgill
- 951,095
- 183
- 1,149
- 1,285
2
Check out the excellent Gitcasts on Branching and merging as well as rebasing.
webmat
- 58,466
- 12
- 54
- 59
0
If you want to pull source without affecting remote branches and without any changes in your local copy, it's best to use git pull.
I believe if you have a working branch that you have made changes to, use git rebase to change the base of that branch to be latest remote master, you will keep all of your branch changes, however the branch will now be branching from the master location, rather than where it was previously branched from.
Lee H
- 5,147
- 4
- 19
- 22