[solutionyogi]

It is better to have a messy but realistic history if you want to trace back what happend and who did and tested what at what time. I prefer my code to be clean and my history to be correct.

^^^ Couldn't agree more.

However, I don't know why people want to avoid rebasing feature branches. Rebasing feature branches means that you only have to resolve the conflict once and have a clean history for your release branch. Granted, it works well in my team where only a single developer owns a given feature branch.

[aidos]

I don't think that's true.

If you have a feature branch with a number of changes in the same place, rebasing on to a branch that also changes in the same spot means you need to fix all of the related commits during the rebase. If it's a big feature that could end up being a huge task.

I may be wrong about that as I'm no git guru.

[solutionyogi]

True. You do have to fix all the true conflicts. But you have to do it only once. If you merge your master, you have to resolve conflicts every time you merge from the master. git rerere could be potentially useful here.

Even more importantly rebase allows you to resolve conflict at individual commit level. During conflict, you can see the exact commit that is causing it, making it much easier to resolve it.

See: http://jeffkreeftmeijer.com/2010/the-magical-and-not-harmful...