"Keeping up" with remote master when working on a long-lived local topic branch

Question

I have been working on a local topic branch for some time, making only a few changes every now and then.

In the mean time, the master branch has evolved significantly. I decided to incorporate the new changes in the master branch into my local topic branch (which barely has any changes in relation to the original master commit that I branched off from):

git fetch
git checkout my_branch
git merge origin/master

but then git warns me with:

Please enter a commit message to explain why this merge is necessary, especially if it merges an updated upstream into a topic branch.

This made me curious. Why the warning? Should I instead do a rebase? or a cherry-pick? And aside from that, how would I use a rebase or a cherry-pick in my case?

Answer 1

There's been some discussion of the wording of this exact message with git's core maintainer because you're right, it isn't very clear.

The puppet labs programming guidelines provide a great explanation for why this is suboptimal and provide a more preferrable workaround:

Work should be done on topic branches and merged in using no-ff. The reason for this is that the git history then becomes a lot clearer. The topic branches group related commits nicely, and merging using no-ff preserves that grouping in history.

Don’t merge your upstream branch into your topic branch if you can possibly avoid it. While this is one way to resolve conflicts between your development and development in the upstream branch, it leads to an unclean history – and especially to having code changes in merge commits, which are super-hard to work with.

We would prefer that you rebase your branch against upstream, so that we don’t wind up with that mess, if you have to adapt to external changes.

Puppet Labs