I recommend squashing your commits before merging back to your main branch.
While the best practices for git state that you should commit early and commit often, this does not mean that your git history should be riddled with multiple, small and insignificant commits.
Such commits will make reduce the readability of your git history.
Here's an example
commit e4b665b4a updated how login works
commit dcd77a46a updated version
commit e4c77b936 fixed some review comments
commit d36a0e6b5 fixed some review comments
commit a69fed5f5 added more test
commit 49945ad19 added in some tests for web client
That commit history doesn't tell me at which commit a feature ends and begins. Add to that other developers merging their branches in to the trunk, and you are going to have a mess.
But contrast that with this history:
commit e4b665b4a added validation for book creation
commit dcd77a46a new route for book creation
commit e4c77b936 added login screen
Aside from the difference in message clarity (done on purpose, to make another point), it's clear to see which commit added which kind of feature. Your peers will thank you!
Side Note: while i haven't added it here, please also include your JIRA/ticket in the commit, to be able to relate it back to a story/JIRA for sanity.
Use tags for releases
This is what i do at my work. And i recommend it.
You should tag releases to demarcate and identify when a stable version was pushed to production and what changes went into that version.
Releases should identify which JIRAs and bugs were resolved by this version and any known issues and work-arounds. This allows other developers using your software to be aware of what surprises are in store (fore-warned is fore-armed!).
[JIRA-1110] fix glitches in validation that trigger when user logs in from mobile
[JIRA-1203] Added new route for creating a new book
This application will not allow login from aa unsupported browser
An added benefit is that you can setup your repo to run CI for tags, that can involve more significant and intense tests (such as performance tests), that would be too expensive and time-consuming to run on ever commit.