Git for solo developer: merge vs rebase
git
Solution
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.
Problem
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?