There's no single right way, but there are a few patterns that actually reduce the daily friction.
Every team I've worked with eventually asks the same question — how do we keep git branches and Jira tickets in sync without it becoming a whole process of its own? I've tried a bunch of setups over the years, some good, some pretty painful, so here's what I've landed on as the version that actually works.
Sounds obvious but a lot of teams still branch off feature areas instead of tickets ("feature/payments" instead of "ABC-204-fix-refund-bug"). Once you tie branches to the actual ticket ID, tracing "why did this line change" back to a Jira ticket becomes trivial, and code review context is right there.
Not one or the other. Branch name gets you traceability at the PR level, commit message gets you traceability at the git blame / log level. If you only do one, you'll regret it during an incident six months later when you're trying to figure out why a line was added.
This is the part that breaks down first on every team. Someone starts a ticket, forgets to move it to In Progress, then someone else picks it up thinking it's unassigned. Or work is done and pushed but the ticket sits in the same column for three days because moving it is a separate manual step nobody prioritizes.
This is honestly the exact gap I built Jitly to close — jitly start ABC-123 creates the branch and flips the ticket to In Progress in one shot, jitly done commits, pushes, and updates the status. No separate step to forget.
Not in a Slack thread that gets buried. Somewhere the whole team can reference — even a one-line note in the README. feature/{ticket_lower}-{desc} is a fine default if you don't already have one.
"What did you do yesterday" is a hard question to answer from memory on a Monday. Pulling from actual commits removes the guesswork.