Git - Merge vs rebase

Unless you have already pushed your branch (and you know others have cloned your repo), I would still do a rebase, as I mentioned in my own answer of "git rebase vs git merge".

Test or not, I usually do a rebase each time I update my local repo (git fetch), in order to ensure the final merge (Feature to master) will be a fast-forward one.

So it isn't just about how your history look, but it is mainly about making sure what you are developing isn't based on an old version of master, and keep working against the latest evolutions done in master over time.

Why not create a new branch to test the merged version? For example:

git checkout -b test-merged-feature master
git merge my-feature
[... do your testing ..]

There's no particularly reason to do a rebase here, but if you haven't already pushed your feature branch, that'd be fine as well. These questions are partly about how you would want your history to look - some people don't like seeing lots of merges; some prefer it as a way of keeping track of which commits contributed to a particular feature.