To rebase, or not to rebase - for me its not really a question. I
generally prefer a clean, linear commit history. Why? Because merge bubbles make
history confusing, noisy, break
The workflow that caused those merges was as follows:
git pull(to bring local up to date)
git pull will fetch any new commits from the remote, and
then merge any local changes in, resulting in the merge bubbles.
A better approach
I typically use the same workflow as above with one tweak. Rather than
pull I use
git pull --rebase which will fetch the remote commits,
and rebase your commits on top of the new commits from the remote. This is the
â€œre-writingâ€ of history folks often talk about.
Make it better, automatically!
You can tell git to use rebase, rather than merge, in one of two ways, depending on your situation.
You can add the
--global switch to have all future branches, in all
repositories on this machine, behave this way.
Get more info
Be sure to check out the git man pages for more info on what those options mean and when you may or may not want to use them.
You might also want to check out my Git Workflows repository
on The GitHubs where you can find a Keynote presentation (or PDF in the Downloads)
git rebase vs.
git merge Complete with