A merge is totally fine, if you really are merging something. But in the case of feature branches you often have the situation, that you work on a very isolated thing. Simultaneously, someone works on the branch which you branched your feature off. You want to get the current state for some reason. By using a merge you would add complexity that is not necessary at this point, because it would just originate in the fact, that you branched off sometime sooner. It would not really be a merge in "content". I find rebasing in this occasion perfectly suitable, since it removes this layer of complexity that noone needs at this point. You just pretend to have branched off later, which is alright. When you are finished with your feature you use a regular merge to get back in your dev branch, since now you really ARE merging something.
By using a merge you would add complexity that is not necessary at this point, because it would just originate in the fact, that you branched off sometime sooner. It would not really be a merge in "content". I find rebasing in this occasion perfectly suitable, since it removes this layer of complexity that noone needs at this point.
What exactly is the complexity you have in mind here? (I'm not trying to be contentious: I honestly don't see it.)
When you merge the dev branch in the feature branch, you create a new commit with 2 ancestors. While this is all done very well in git and allows for perfect inspection, it makes it nonetheless harder to follow the history of your feature branch, since now you have two sources for changes. I just find it easier to make the history linear in that case, because it is easier to analyse in retrospect.
I actually prefer having two ancestors, because you can analyse different kinds of change in isolation. If your branch was to add a new widget to the UI, and there's a regression I'm trying to find in the backend data munging code, it's better if I can trivially ignore all the changes from the new-ui-widget branch, because I know that's very unlikely to have broken the data munging. That's harder to do if you've linearised the history.
Not really, because every changeset from the new-ui-widget branch shows up after the point at which the rebase happened, so there is a clear cutoff in the git log between branch changes and master/upstream changes after you've rebased.
