8

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?

Amelio Vazquez-Reina
  • 91,494
  • 132
  • 359
  • 564
Josh
  • 11,979
  • 17
  • 60
  • 96
  • possible duplicate of [git workflow and rebase vs merge questions](http://stackoverflow.com/questions/457927/git-workflow-and-rebase-vs-merge-questions) – Roman Oct 11 '12 at 15:38

1 Answers1

6

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

Community
  • 1
  • 1
kayaker243
  • 2,580
  • 3
  • 22
  • 30
  • When they said: `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.` Do they mean *rebasing upstream onto the topic branch*? Or the other way around? – Amelio Vazquez-Reina Oct 11 '12 at 15:56
  • 3
    it's basically saying: rebase when moving changes from upstream to topic branch, merge when moving changes from your topic branch to your upstream branch. – kayaker243 Oct 11 '12 at 19:34
  • 1
    The other way around. I rebase my topic branch onto upstream frequently as both I move forward in time and upstream moves forward in time. `git rebase -i master` while I have my topic branch checked out. – Jeff McCune Oct 11 '12 at 23:33