[hammadfauz]

If you do these things:

* File issues in a project tracker (Github, jira, asana, etc)

* Use the issue id at the start of every commit message for that issue

* Use a single branch per issue, whose name also starts with the issue id

* Use a single PR to merge that branch and close the issue

* Don't squash merge PRs

You can use `git blame` to get the why.

git blame, gives you the change set and the commit message. Use the issue id in commit message to get to the issue. Issue description and comments provide a part of the story.

Use the issue id, to track the branch and PR. The PR comments give you the rest of the story.

[mb7733]

Overall I agree with the approach, but just wondering, why do the first point if you are already doing the last two?

> * Use the issue id at the start of every commit message for that issue

> * Use a single branch per issue, whose name also starts with the issue id

>* Use a single PR to merge that branch and close the issue

To me the noise at the start of every message is unnecessary, and given a lot of interfaces only display 80 chars of the message by default, it's not negligible.

[hammadfauz]

If the pattern is consistent, it gets easier to ignore the noise when you don't need it. Like, a three/four digit number or a 3 letters and 3 numbers separated by a hyphen.

Sometimes, an issue might depend on another issue and contain commits from the other branch. Tagging each commit makes it easier to pinpoint the exact reason for that change.

[4star3star]

This seems reasonable to me. Devs and BAs flesh out business processes and ultimately document decisions in our Jira issue comments. When you have an issue id handy, it's not that hard to go read what the rationale was for a feature.

I have been ignoring Jira's AI summary, but I suppose that could be useful if the comments were very long.