Reason I like git is because I use like 2% of its features. I don't fall for propaganda that I need to use bisect and co. 99% of git commands I call are aliased to 3 characters, so it's dense terminology doesn't bother me.
I don't understand why anyone would say you have to use it. It does a very specific thing, namely finding the source of a regression between two commits. If you need it you'll know.
Does it work well with a classic merge workflow? I haven't worked that way (without rebasing) for a long time.
That's also useful for bisecting, as you can first find the feature that is buggy and then find the commit that introduced it.
I use the commit message to add ticket numbers to things to group commits.
I prefer to have everything in a single source of truth (git), so everything is in commits. Your tickets are my merge commits.
Was that 'may I ask'?
Not that often, but not seldom. Its useful if you have a bug, that isn't obvious where it comes from, but easily testable. Then you just write a test and let git figure out where it comes from. The test doesn't need to be automatable. I also used it for firmware that needs to be flashed and the bug effected in an LED blinking incorrectly. I still saved a lot of time.
Yes, can't type sometimes.
I see. Maybe it's just what kinda of code and/or how I write it, usually pretty clear which abstraction isn't doing its thing. From there, it's either clear what is the bug, or git blame will reveal what changed.
This has a much higher chance of succeeding if you maintain strict boundaries and isolation which isn't always possible.
It's a command that is needed rarely but there's no replacement for it in some situations.
It might be slightly more tedious but couldn't you just do the same thing manually and it would add just a couple minutes to the search and you would still save weeks? I like the ergonomics but only use it once every couple years.