You don't need one more special tool. Keeping that in sync and tracing back will be painful. Some places do each change / feature as an issue with a descriptio

You don't need one more special tool. Keeping that in sync and tracing back will be painful. Some places do each change / feature as an issue with a description of the rationale and reference the issue using some shorthand syntax in commit messages. This works reasonably well. Just realize how much knowledge and value you will accumulate there. Host a free solution for your issue tracking yourself to avoid losing it all when services close or management decides to change provider. As you are learning now, having a trail of reasons 1, 2, 5, or even 10 years later can be very valuable. Keep design decisions and architextual overviews in the source code repository as plain text docs using some lightweight markup like .md / .rst. If it is not in the repo it will get lost, outdated, not everyone will have access by default, and you may not get the same level of traceability. Add to your review checklist that why things were done the way they are should be mentioned. Sometimes that is a separate .md file, other times it is 10-30 lines at the top of a source code file.