Let’s say that I’m going to start working on a new thing. OK. Here we go!
$ git checkout develop $ git pull origin develop $ git checkout -b new-thing
So then I work for a while implementing the new thing, and – for whatever reason – I need to get changes from the develop branch into my new work.
Potentially controversial statement
You probably don’t need the latest changes from develop , so the first thing you should do is ask yourself:
Do I really need the changes from develop ? Or can I just keep working on this branch as-is?
But let’s assume the answer is ‘yes’.
One thing you could do: merge
You could just merge in the changes from any branch to get up to date.
# Assuming you're on your new-thing branch already $ git pull origin develop
This will absolutely work, and it will also completely bork the history of your feature. Instead of a nice, linear history of your feature, there are all sorts of unrelated changes in there. This is hard for other people to review, and it makes the feature nearly impossible to cherry-pick into production if necessary.
A better thing you could do: rebase
Rebasing is a little scary. After all, you’re rewriting history. That sounds bad.
But there is 1 sure-fire thing that we can do to make it less scary: never rebase on a “public branch – like develop, master, release-, & hotfix-* . Let’s try it:
# Assuming you're on your new-thing branch already $ git pull --rebase origin develop
Hey, look! It’s basically identical to the other one. There’s just that 1 little flag. That’s not scary at all. Cool.
What’s the benefit?
Glad you asked. The benefit is that now your commit history is linear and easy to read. Code review is easier because it’s not littered with unrelated changes. The git history is easier to follow because there’s not a lot of meaningless merge commits. And you – by extension – are awesomer.
So, the official BerniePortal development team position on merging versus rebasing is that we always rebase when incorporating “upstream” changes.