
Ask HN: Relation between commits and issues - qualsiasi
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&#x27;m a not-so-senior developer so I&#x27;d love to hear some of your considerations about it, especially from more experienced developers.
======
welder
Linking every _merge_ 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.

------
cimmanom
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.

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.

~~~
qualsiasi
I'm not willing to enforce one commit per issue, but one issue per commit. An
issue may have, of course, multiple commits (by multiple people maybe) but I
wouldn't allow any single commit without referring an issue.

~~~
cimmanom
I’ll sometimes let a commit reference multiple issues (no point in 3 commits
to fix 3 typos on the same page of copy, for an extreme example). But yes,
that’s a good practice.

