Depends on your project/business. On my current job, I very rarely go back to see when something was changed, because the business requirements are very straig

Depends on your project/business. On my current job, I very rarely go back to see when something was changed, because the business requirements are very straight forward. A change needs to happen, and the implications are clear. Also, no one really documents discussions systematically, commit messages are rather short etc. Not much value can be extracted. On my last job, a system with over 15 years of history, my team was often puzzled with the existing codebase and the seemingly weird things it did. "Who wants this?", "Is there a usecase for this?" and "Do any of our customers actually expect this functionality if we remove this?" was a frequent question. Then we'd check the commit history and get the 3-4 tickets involved in the functionality's history. Long discussions and back and forth with the client, explanations why the functionality was being added etc. This archaeology was so frequently fruitful that all the team engaged in it.