| Disagree. No one maintains change logs in their repos most times, so a linear git history where you rebase existing branches on top of their base branches allows for a clean commit history on new features to be merged in which can then be squashed down for a linear commit history on the trunk branches. Then you can use things like bisect, and just... ya know, read through your change log when you need to. Shoot, you can even add a few details in the notes while you're at it. How about a link to the ticket and PR at the very least with some notes on implementation. That's my approach, it really doesn't take much time. But hey, if civil engineers had the level of rigor software engineers do we'd all be dead. So you live with what you've got, do what you can on your own branches, and just accept that no one cares about having a clean git history cause we can't be bothered as a profession to spend a couple hours learning how one of the most important tools we use every day works. |