What I do myself & highly recommend too:
Use feature branches for features
Once the feature is done, rebase it to origin/master
Then merge it into master with --no-ff to intentionally create a merge commit.
This produces a very clean commit history - you know which commits came from a specific feature branch, and which ones were commited straight into master.
Take a look at my recent project as an example -- https://github.com/sarpik/turbo-schedule
The workflow looks as follows:
git checkout master
git pull
git push # do not have unpushed commits
git checkout -b feat/my-dank-feature
# develop
# commit
git fetch
git rebase -i origin/master
# rebase interactively - you can even rename the commit messages to comply
# with semantic versioning via REWORD etc.
# either
# a) merge via
git checkout master
git pull
git merge --no-ff feat/my-dank-feature
# or b)
git push -u origin feat/my-dank-feature
# and create a PR & merge it from github
# (without additional rebasing/squashing, since we've already rebased)
# I highly prefer the b) approach - by creating a PR, you get additional benefits -
# you can later link to it, see the commits & changed files more clearly, discuss etc.
and that's it!
Also, I'd recommend ditching the develop branch for projects that do not have bigger teams & do not require multiple change previews before merging into master. It just slows you down, your hotfixes, releases & the synchronization between the master & develop branches becomes a mess, and the whole commit history becomes wrangled & unclear.
In the workflow example above - you automatically avoid the develop branch, since you're only creating feature branches straight from master.
P.S. The commit log is produced via git lg:
[alias]
lg = log --graph --pretty=format:'%Cred%h%Creset -%C(yellow)%d%Creset %s %Cgreen(%cr) %C(bold blue)<%an>%Creset' --abbrev-commit(~/.gitconfig from https://github.com/sarpik/voidrice/blob/master/.gitconfig)