What git commit practice is better?

I truly believe that to have one commit on one issue is a good practice. I'm sure I read it somewhere in an article like “Best practices”.

As such, my workflow has been the following:

• For a new issue, I create a new local branch with git checkout -b new-issue.
• Commit all changes into it. Sometimes this involves lots of commits.
• When done, I squash the commits and rebase them into current thematic branch.
• If something goes wrong, I can git revert the commit, find the bug, fix it, and commit new patch into the thematic branch. I won't change the remote repository’s history.

But today, I was surprised to hear the following workflow:

• Create new branch for the new issue.
• Commit everything into it.
• Use merge --no-ff to merge the issue branch with thematic branch (so we’ll have “merge-commit” that we can revert).
• If something goes wrong, we can use git bisect to find the bug.

According to the 1st approach, we’ll have a clean git history, and no idea about overhead branches used during development.

According to the 2nd approach, we’ll have a very messy history, with a lot of ugly, unnecessary merges and commits for just one issue. However, we can use git bisect to find bugs. (Perhaps this is better for refactoring?)

• What pros and cons do you see for both approaches?

• Which approach do you use, and why?