It depends where you are in your career and what the industry at the time offers. For requirement, use any kind of issue tracker and connect your commit with i

It depends where you are in your career and what the industry at the time offers. For requirement, use any kind of issue tracker and connect your commit with issues. Jira, people here hate it for various reason. But it get the job done. Otherwise GitHub issue would (there are problems with GitHub issues, e.g. cross repo issue tracking in a single place. That's another story) For QA, you want your QA be part of the progress tracking and have it reflected in Jira/GitHub commit. One thing I think is of equal importance, if not more, is how the code you delivered is used in the wild. Some sort of analytics. Zoom out a bit, requirement is what you THINK the user want. QA is about whether your code CAN perform what you think the user want plus some safeguard. Analytics is how the user actually perform in real world A bit off topic here, QA and analytics is really two side of the same coin. Yet people treat it as two different domains, two set of tools. On one hand, the requirement is verified manually through hand crafted test cases. On the other hand, production behavioural insight is not transformed into future dev/test cases effectively. It is still done manually, if any. Think about how many time a user wander into a untested undefined interaction that escalated into a support ticket. I'm building a single tool to bridge the gap between product(requirement and production phase) and quality (testing)