Code/Ticket Linking

Why is it important to link commits with tickets?

Linking commits with tickets makes it possible to see who was working on which task when and for how long without time tracking so that you have ground truth about development effort. This makes it possible to analyze estimate accuracy with hourly precision on a per-ticket basis, as well as track overall development effort allocation by project.

How does minware determine which ticket is associated with a commit?

minware uses the same set of checks that the Jira/GitHub integration uses to find the ticket ID for each commit. It looks in the commit message, branch ref name, pull request title, and pull request body to find the first reference to a Jira ticket.

Additionally, we apply a number of heuristics to deal with typos and case sensitivity to ensure that we reconstruct as many links as possible while minimizing false positives.

How do you link identities between Git and Jira?

minware automatically resolves identities between Jira and GitHub/other Git systems using a series of heuristics based on names, email addresses, and who the assignee was on a ticket when commits were made. This links aliases so that everything works out-of-the-box with zero effort. In rare corner cases like an email address being reused, you can manually override Git/Jira identity associations.

Does minware handle squash and rebase merges?

Yes. Though squashes and rebases will break the original link between branch commits and main commits in the Git commit graph, minware rebuilds those links using pull request and commit metadata so you can see which commits are associated with each merge regardless of merge strategy.

Does minware handle multiple levels of pull requests and stacked pull requests?

Yes. We associate each commit with the first pull request that merges it, and also with any later pull requests that merge into other branches on the way to the final main/master merge. If earlier pull requests are missing tickets or reviews, minware looks at the first pull request in the chain that does have a ticket ID or review when assessing each commit.

How does minware handle non-trunk Git flows that first merge changes into development or staging branches?

minware looks at initial pull requests including pull requests into a non-main branch to find tickets and code reviews, but also traces when intermediate branches are finally merged into main/master to compute the cycle time from branch merge to main merge so you can see how long it takes each commit to reach production.

How does minware deal with subtasks, tasks, stories, epics, and other ticket hierarchies?

minware will link commits to tickets at any hierarchy level based on the ticket ID found in commit messages, branch names, and pull requests. Then, when reporting on higher-level tickets and entities like sprints, minware will roll up all of the commits for tickets and their children.

How do you exclude bot users?

minware automatically detects and excludes commit and ticket activity from bot users using name patterns and account type metadata. You can also override these settings if you have bots with unusual names like Joe Smith.