There is no "best practice" here. The choice is yours.
Some people keep a merge commit, even for a fast forward, because it keeps a very good record of when a branch was completed. These people prefer "complete and accurate" history over a "clean" history.
Some people avoid merge commits, even rebasing their branches, because it keeps the history easier to read. These people prefer "clean" history over "complete and accurate" history.
Most people choose a middle ground, where small changes are rebased and squashed before making them public, which makes each branch clean. The branches are then merged as normal, to preserve the complete and accurate history, at least for the big picture.
Myself, I prefer to use merge --no-ff
when completing a feature branch, and I lean towards "accurate" over "clean", but I try to keep the noise down with squashes and rebases here and there.