Overall, we use a fork-and-branch model. The rest depends on where in the project lifecycle things are and what our customer-dictates are.
Early in a project-lifecycle, there often aren't "issues", per se. It's usually "we need IOC by <insert date that's some fraction of the length of time that it likely ought to be>". It usually works out to a flow like:
<insert date that's some fraction of the length of time that it likely ought to be>
Because we do work for multiple customers, things begin to deviate once the above is done. Some customers want issues managed in Jira. Some want issues managed elsewhere. Some are fine leaving them wholly contained within a given git service. Once we're to the point that there's discreet defined tasks that need to be individually coordinated and tracked, then we start using the customer-preferred tracking system. For tasks tracked wholly within the git service, we usually just do "Issue_<NUMBER>" to reflect the git issue-ID. If customer is mandating Jira, then we usually do "<PROJECT_ABBREVIATION>-<NUMBER>". For other issue tracking systems, we do either whatever's native to that system or whatever the customer asks.
...And if we're doing stuff on spec (anticipating a need for a customer or our own organization), then it's pretty much dealer'sdeveloper's-choice.
We're a place where coders share, stay up-to-date and grow their careers.
We strive for transparency and don't collect excess data.