Over the years I've used Git for most all of my programming work. In the past, I have used SubVersion, CVS, and even keeping copies of the latest working build in a USB drive!
Learning Git was definitely a big change and required some adapting to a ton of new concepts, but once I had I really wondered why it took so long for this to come along.
As I've used Git over the years, I've developed some habits, some bad, most good.
One of the big ways I prefer to use Git is having multiple branches going at any one time. It's easy to jump back and forth between one or the other and not lose any information. git log provides a huge productivity boost to help remind me what I was thinking 2 weeks ago when I wrote that huge commit.
I tend to work in JIRA for most of my projects and so branches are usually named after ticket numbers. This really helps when I need to go back through my commit history when researching past issues. Since most of the correspondence regarding implementation and specifications are located in a more content-friendly area outside of Git, it's much easier to correlate commit messages or comments to specs this way.
Free-form branch names were a really new concept for me to wrap my head around after coming from other version control systems. It was only after a couple resourceful coworkers repeatedly suggested to me that branch names don't need to match the origins, I was able to keep my work in more specific contexts for later reference.
Since I use multiple branches and normally try and keep the names related to a ticket I am working on, switching between branches is very effortless.
Sometimes work isn't in a form I'm happy with writing a commit or I'm just lazy so I git stash it. Typically I stash when I have something I don't necessarily want to commit right away and can't make up my mind about what branch it should go on. For instance, maybe this is something that isn't really related to a feature but it was helpful at the moment to write.
I have a pseudo stash method I also like to use, which is just a combo of git commit and git reset HEAD~1, however the only problem with this is I typically lose whatever commit message I made when I committed it.
What I like about it over the stash is it's easy to use the commit with other git operations. If I want, I can easily rebase or merge it.
Ah, the old --force push. The namesake of this site and kind of an annoyance that everyone is far too familiar with, and you feel dirty every time you have to use it.
Everyone has that one coworker who likes to --force push because git is hard. You try and tell them that it's bad and causes conflicts.
Some clients I work with have some sort of CI/CD process utilizing multiple branches, either forked from a trunk branch at a given time or when a feature is complete. Most just utilize a single branch and deploy commits are various stages of completeness and verification (feature complete, release ready etc).
There are a ton of different perspectives here, and none are wrong and none are right, however each does it's advantages.
I tend to like to keeping features in separate brances off of the trunk branch and only merging a feature to trunk after it's satisfied the product requirements and a full regression test has passed. It's only then that I'm really comfortable merging it and ready to have it deployed to production.
One thing I like about a single branch is that no branch ever goes stale and everything eventually finds its way to trunk.
A common practice I've seen with release branches is bugs and hotfixes. When a bug is found in an existing release, the sprint branch needs to be forked and a patch created (this is assuming the sprint branch was not deleted!). After the patch or bugfix has been pushed to the sprint branch, it also needs to be cherry-picked to the trunk branch (or later sprint branches if multiple currently exist in production-like environments).