5

I'm a solo developer and am just getting into using Git with private BitBucket repositories. The one thing I'm not clear on is Merge versus Rebase.

I frequently switch between desktop and laptop and have been using BB to have access to the latest code on either platform. I've been using rebase when I load the latest committed code, because I think it essentially clears out everything on that platform (desktop or laptop) and ensures I have the identical code as committed to BB. Is that correct? When should I use merge to such an action?

mraviator
  • 4,034
  • 9
  • 38
  • 51
  • Don't really understand what you mean saying `I think it essentially clears out everything on that platform (desktop or laptop) and ensures I have the identical code as committed to BB`? – Max Komarychev Jul 27 '13 at 11:50
  • Basically, when I pull and rebase, I think it updates the files on my hard drive to the versions on BB. But does Merge do something differently? – mraviator Jul 27 '13 at 12:28
  • 5
    If you want to use Git effectively, I highly recommend the [free online Pro Git book](http://git-scm.com/book), in particular chapters 1-3 and 6-6.5. –  Jul 27 '13 at 14:41
  • Nice Cupcake! thanks. – mraviator Jul 27 '13 at 18:34
  • Check out [this](https://stackoverflow.com/a/46708899/3094731) answer. – Abdullah Khan Nov 05 '17 at 12:10

2 Answers2

7

rebase and merge are different kind of strategies for bringing your branch uptodate with another branch. rebase changes the history to the point where both branches started diverging. merge on the other hand, does not alter history and might create a new commit to show the merge of two branches.

See also this document on rebase vs merge. Bottomline: use rebase for unpushed changes to create neat history; otherwise use merge.

Update: Linus wrote about this in 2009, see his advice on git rebase and merge. Bottom line: rebase only your own private stuff, with caution. If your commits have been pushed, no more rebasing.

Bouke
  • 11,768
  • 7
  • 68
  • 102
4

merge does as the name says, it combines two branches of development into one. So imagine you have a master branch at commit M1. Then you work on your notebook and create commit N. And you also work on your desktop and create commit L:

   N
  /
M1-L

When you merge N into L you combine the changes and get new commit M2

   N
  / \
M1-L-M2

This keeps all the changes as they were made, but you get these little double paths, which can become pretty confusing, especially when you have lots of them.

Then there is rebase. Starting from the same situation a rebase takes one of the commit N or L and pretends it was made after the other. This results in a new commit n'

M1-L-N'

N' and M2 have the same content, just their history looks different.

As long as you are alone
It doesn't matter. You'll have a current state both ways

If you are in a team
The difference becomes important:

When you rebase a branch that got already pulled by somebody else he might see some confusing effects since the branch he was working on suddenly contains completely different commits.
So you don't want to rebase stuff that went public.

On the other hand, if you have 10 developers commit and merge like hell the history becomes confusing and you might prefer to have developers work on private repositories and then rebase before push to the integration branch.

Ahmed Nabil
  • 17,392
  • 11
  • 61
  • 88
Jens Schauder
  • 77,657
  • 34
  • 181
  • 348