Issue key in every commit message? [closed]

Question

Feature branch names already contain the issue key (ticket number). Should commit messages also contain them?

Pro:

• easy to see where a commit belongs to.
• better for third-party software tracking commits for issues.

Contra:

• developer needs to repeat themselves. Issue key is already in the branch name, and retyping it is a waste of time and also may be done incorrectly.

Answer 1

DRY meet Reality

Let's just presume that a ticket number into an external system will still have some meaning in 10 years.

Now, let me push you on what the difference is between a commit and a branch.

• A commit is a durable write-once record representing a single node in a DAG describing the changes to a file-system.
• A branch is a pointer to a commit.

What happens when you delete one of them?

• A commit? It erases all possible file-system versions based upon that commit, and the version of the file-system represented in the commit itself.
• A branch? By itself nothing much... Assuming of course it wasn't the last owner of a particular DAG, in which case git will forget the commits not in the DAG of another branch.

What happens when you change them?

• A commit? ... You get a completely new commit, the original has NOT been changed.
• A branch? Sure why not, point that where ever you want.

So put the important tracking information in the branch? Well we can make that mean anything we want, or erase it quite simply.

Put the tracking information in the commit? Its still going to be in that commit. Even if you delete the branch.

Answer 2

Branches are temporary and arbitrary constructs. Your branch will eventually be gone - the branch name is then gone as well... or, well, it might live on in the default commit message of a merge commit.

Furthermore, in most flows the branch is an ownership thing: Your workflow will probably have personal branches, team branches, project branches. One and the same commit will eventually exist in many of those. More to the point:

1. It will probably be created on a personal branch - most importantly named after the developer.
2. It will next be merged into a team branch for integration - most importantly named after the team.
3. It will eventually be merged into a project branch for release - most importantly named after the release step ("development", "rc", "release", "master", etc.).

All those kinds of branches have little reason to be named after an issue.

For 1. it is convenient to also include the issue, because you will likely work on more than one issue at a time, e.g. one in development, one in review. Given that issues usually have an assignee, one may then drop the owner from the branch name - this becomes inconvenient, though, in flows where after-development-but-before-closing you reassign the issue to other people (reviewer / tester / product owner / etc.).

For all other branch types it will be detrimental: What of, say, a branch containing 20 issues... pretty long name, huh?

Long story short:

• It is important to reference the issue in the commit message.
• It is not (generally*) important to reference the issue in the branch name.

*- "generally" might be beaten by the requirements of specific third-party tool chains, most likely for auto-generating <tracker>-to-<anything else> links. Those links, of course, behave just like branches and commits themselves: Those to the branches will vanish (with them), those to commits will remain (with them).