Hi, today I stumbled upon an email which stated that there is no such thing as a correlation between issues (tasks, bugs, ..) and commits.<p>I, personally, think that such a relation exists and every bug should be fixed with one commit referring the bug (ok, if a commit solves two or more bugs this may not be true, but just for the sake of simplicity). I also strongly believe that any source code commit should be linked to some sort of tracking system which makes clear WHY someone would change the codebase.<p>I'm a not-so-senior developer so I'd love to hear some of your considerations about it, especially from more experienced developers.
Linking every <i>merge</i> to an issue/ticket is standard practice in companies already. Individual commits not, but when squashing and merging to master it's common to have the commit message reference the issue/ticket. Every merge can easily have it's own feature/bug ticket.
Yes, a policy that every commit must reference an issue in the tracker is useful. It makes it possible to cross reference the history of the codebase with the discussions that occurred around it and the reasons for the changes in greater depth than a commit message could cover.<p>I find the one commit per issue policy too restrictive. It’s a terrible idea for larger projects and IMO unnecessary even for smallish fixes. But then, I’m also someone who strongly dislikes linear histories.