The conversations on Hacker News on a blogpost about the naming of feature branches stirred me to share my thoughts on the topic. It may seem like a trivial topic of discussion but as the saying goes:

There are only two hard things in Computer Science: cache invalidation and naming things. - Phil Karlton

The aforementioned blogpost outlines conventions on how feature branches could be named; prepending with an ID from an issue tracker and using hyphens as separators for a short description of the feature the branch addresses. For example:

722-add-billing-module

This would work, but in the real-world, feature branches rarely address such a large item as "billing module". While developing, we typically work on smaller subtasks of such a feature. Ideally, of course, each subtask would have issue tracker IDs but they often don't. Branches related to the same feature would typically look like this:

billing-module-setup billing-ui-changes billing-database-migration update-redis-keys ui-tweaks transactions

Given that this is the case, both GitHub and GitLab have adopted referencing the issue in the commit instead as the solution for connecting to the issue tracker.

The naming of feature branches then, depends on their purpose: they should be short-lived, task-oriented and, deleted when they're merged. Their purpose is agility.

While I agree with the kebab-casing of branch names, as developers we should remain free to name our branches as we see fit. Feature branches should stay lightweight and should not be used to create yet another process.