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


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


  • 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.
  • 1
    There is really no answer to this. It depends on what you're trying to achieve and how all of your tools (issue tracking, code review, source code repo) work together. There's also some level of how you configure and use tools, as well. Without more information about your objectives and environment, it is very difficult to give a good answer.
    – Thomas Owens
    Apr 22, 2022 at 13:13
  • side-note: the additional manual effort can easily be automated away, e.g. with a hook that prefixes every commit with a prefix pulled from the branch name... Apr 24, 2022 at 7:15

2 Answers 2


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.


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

Not the answer you're looking for? Browse other questions tagged or ask your own question.