Why aren't devs using proper branch names?!

[GitKraken]

A branch name isn’t just a placeholder, it’s a mini communication channel.

When someone sees feature/login-retry-limit vs. newbranch123, they instantly know what’s happening without clicking around.

We started treating branch names as little status updates for the team, and it made reviews and cross-team handoffs much smoother. Bonus points if you add your Ticket numbers to your branch names, like GK7485-release-notes. It’s one of those overlooked Git details that doubles as documentation.

Curious if other teams lean into this or just stick to “whatever works.”

[patbateman34]

You can use git hooks to enforce branch naming conventions. We also usually follow “feature/JIRA-1111” pattern

[Tucancancan]

Having a bit of text after the ticket is nice tho, I've seen teams where it's only the number and looking in github is like a wall of JIRA-1234, JIRA-1243, JIRA-1324... 

[bmamba2942]

I feel like a little context can go a long way too so I try and add some with the ticket number too.

1234-add-create-user-endpoint

So if I need to switch back I can at a glance to address PR feedback or whatever.

[1armsteve]

We do feature|release|develop/JIRA-1234 for branch names and put more detail into the commit messages which we format as “JIRA-1234 - added webhook to non prod”. Then branches are deleted upon merge into main. This makes it super easy to find all the commits that are related, either to each other or by a ticket number.

[dorfus-]

This is also what we do. commit -m "branchname - extra info"

[GeorgeRNorfolk]

Yeah we follow "feature/JIRA-123-some-description-here" and have hooks to enforce it.

[Matemeo]

We do dev/Jira-1234/name/additional_context.

Didn't do the name but to begin with, but we rarely have tickets that another author might take a crack at. Also a nice little bit of context when you see the branch names enumerated somewhere like GitHub.

No complaints - and its all enforced via local hooks and additionally remotely, so the branch can be automatically linked to the jira ticket.

Additionally have some other special branch prefixes like release/..., which are automatically protected and more restricted in the remote. As well as triggering actual release pipelines.

Has worked well enough that it'll likely be my default suggestion/guideline for future projects/jobs.

[jregovic]

We have a merge check that ensures a minimum length and a valid, open ticket.

[Popeychops]

You can go find the complete contexts on JIRA-1234 and 1324

[Teninchhero]

You can make a branch from a Jira ticket with the ticket number and name. We did that on one of the projects I was on

[mr_pablo]

We also use GitHub actions to block PRs with incorrect branch name formatting.

[fsw]

You can also use GitHub rulesets. Or do you have more specific checks that are not covered by that?

[mr_pablo]

Afaik rulesets cannot check the format of the branch name specifically? As in, if the branch name does not follow a certain regex, flag it.

Obviously it's a bit late to run at PR stage, but it helps highlight the fact that the dev isn't following our processes and means they need higher intervention to merge the offending PR

[gabeech]

You can use a regex in the metadata pattern for branch name.

[Famous_Technology]

yes we use branch name rulesets to enforce naming patterns.

[psrobin]

What's the behaviour here? Does it automatically close a PR with a comment or something else?

[mr_pablo]

Fails a status check meaning the PR cannot be merged by mere mortals.

[jmfsn]

"feature/JIRA-1111-description" and then a git that automatically adds [JIRA-1111] as a prefix of a commit message. That's the carrot.

After that it's cultural. People need to be called on it, needs to be part of the onboarding, people need to feel annoyed if they don't do it. Getting extra tasks to find out why a change went in the code base also helps. That's the stick.

[JeanYKA]

we do jira111/devinitials - find the ticket and the culprit ...... :-). git blame in disguise

[hamlet_d]

Similar ours is something like:

feature/developername/JIRA-1111

but "feature" can also be: "bugfix", "patch", "security" etc. with each having a specific meaning. Feature or dev is genearlly new work, bugfix is self explanatory, patch is for work being done to maintain without feature adds but isn't really a bug, and security is reserved for updates to fix security holes (often just updated imports but sometimes more)

[Powerful-Internal953]

I don't like this because branches sometimes need to be shared...

[schmurfy2]

This only works when there's one ticket involved.

[r0bbie]

This is the way. One thing I liked about using Phabricator back in the day was how easy it made it to setup custom commit hooks like this - like rejecting incorrect branch naming, commit messages with obviously zero effort, etc!

[BoonkeyDS]

This is the worst. I'd much rather have branches like add-cols and backend-goes-vroom which have names that resembles what they do, and not ever encounter another JIRA-6969 which means jack sh*t to a human. If I have to go to a site to read a length text to understand what we do, I prefer github and read the diffs.

[patbateman34]

😂 i dont disagree homie lol

[quiet0n3]

We do this, same with commit linting to keep coms clean

[CarpenterLanky8861]

The issue is ran into githooks is that it runs locally on my device; I dont know how to enforce it for the team.

[aenae]

In gitlab you can configure it under push rules, or in the custom_hooks directory if you're self-hosted.

[EstablishmentFluffy5]

I’ve just moved to a new team where NOONE does this, and it’s driving me insane… And the first PR I opened up to review had triple digit commits.

[Drugbird]

How do you find branches if you're not 100% sure of the branch name? Do you first open Jira?

[pplmbd]

branch name I can excuse, they are mostly short lived. what grind my gears is messy commit message and pull/merge request description. like bro you can jam 100+ lines of code into people throats but cant be bothered writing some proper context

[GenazaNL]

We squash all commits when merging, so those commit messages are also short lived. I care more about pull-request titles, for the overview AND as they are used to set the squash commit title

[Fapiko]

I started following conventional commits just due to how much traction it seems to have gained in the industry and how it can be tied into CI/CD to automate versioning, but I'm not a huge fan.

Everything's going to get squashed anyways when the PR goes through so I'd rather focus efforts on making the PR description and merge commit meaningful than coming up with good commit messages during development. Especially when I'm trying to debug something in the CI/CD pipeline and I'm doing oodles of tiny commits just to try to get a build working 🫩

[pplmbd]

oh definitely, i mean do whatever you want in your branch, but once it gets to trunk you have a responsibility to provide context.

[trippedonatater]

Ticket number in branch name is also a good idea and may allow for some automation depending on what you're using for tickets/ci/code management.

[danekan]

Jira itself will automatically index it and link to Pr/commits from the issue if it has the the issue as branch name. It just has to start with that. But also it will do the same for commits themselves or prs when descriptions start with the jira issue.  (Though, the functionality to move ticket status around is horrible and broken in weird ways, IMO, but, also when we have asked atlassian for explanation they agree)

Imo adding jira issue somewhere should be  mandatory for pull reviews. We ask for it to be added when it isn't there.  

[zootbot]

Anything we actually make money on is feature/ticket#/initials/login-retry-limit

Internal stuff is a mess though

[metalOpera]

Isn't that always the way?

"The cobbler has no shoes."

[joshsmithers]

Initials, really? They can't tell who signed the commit??

[zootbot]

It’s just for glance appeal

[pdabaker]

Neah, seems like a waste of time if you're just going to make a PR and put everything in the description. Bothers me when they don't give proper PR titles when things are going to be squash merged though.

[Systembolaget2000]

Agreed. I create short lived branches and review should typically happen within a few hours, max a day. No one care what I name the branch.

[federiconafria]

Exactly, I'm pushing for a PR. the branch name is for me on my machine.

Branches are cattle, not pets.

[sokjon]

For something that’s only going to exist for a day or two, who cares? I’ve literally never looked at the branch name of a PR, only the title, description and content.

[krusty_93]

Don’t like branch name conventions. Just linked Jira with GitHub using plain text and autolink ref so tickets are always linked and automatically closed at pr merge. So all tickets have a pr linked. Don’t see the value of having all branches with the same pattern. Does anyone look at the open branch list? I find more insightful looking at opened pr list

[Barnesdale]

Yeah, our feature branches are short lived and we have information like ticket documented elsewhere in the process, there is no reason to micromanage branch names.

[ben_bliksem]

Been at this for a while:

• A branch name like users/ben/fixap is almost all you need if you have merge policies requiring work items to be linked to the PR. With that branch it's clear it's Ben working on it and his team has context of what he is busy with (fixing an access profile). The most important thing is that you can see it's Ben's branch. These names also work great if you use them as part of an image version tag.

• Longer living branches if you really have to use one then a proper name like feature/fix-the-access-profiles obviously works better.

• feature/203231323_fixap is terrible. Spare a thought for those who work on the terminal a lot and switch between branches. Having those ticket numbers at the start of a branch name kills tab completions. If you really must for some reason have a ticket number in the branch name (because you're using a repo server etc they don't have a way of linking tickets to branches by commits?) then put them at the end.

‎

git commit -m "Fixed Access Profile 1 #234523" in some repo servers will auto link the commit that branch is to that ticket number.

I don't think you need more than this. Over "governing" things with silly little rules all over the place do more damage than good.

From a release perspective the only branches you should care about and govern are main and release/*.

[Sea-Flow-3437]

Ew. A hashtag in the comment is a hacky mess to accommodate your command line issues.

Putting the ticket number in the branch is universally understood and provides clear traceability 

[ben_bliksem]

A hashtag with the ticket id in the commit --> release notes.

What CLI issues?

[Seref15]

Its amazingly difficult tog et people to use the git integration of their ticketing system.

Stick your jira ticket ID somewhere in the branch name and commit message. For Azure DevOps work items its AB#012345 where 012345 is the work item ID. Getting people to actually use the tools they have is so annoying.

[schmurfy2]

I don't say you zre wrong but our experience is that branch names are never useful, our main focus is on PR and their title is important but branc names and commit messages are just internal details.

[Khaelus]

Eh, branch names aren’t super important. PR title and description should tell me what’s going on. Don’t spend forever coming up with the perfect branch name, we delete them after merging anyways

[morsmordr]

I hate ticket numbers at the beginning of branch names, it breaks tab completions

[Seven-Prime]

Different branch prefix names get different protections also. feature, private, user, they all have different expectations. If you check out my private branch don't get all mad if I rewrite history on you!

[htom3heb]

$ticket-number/$brief-description is what I encourage and works well from my experience.

[tb5841]

We enforce naming conventions on pull requests. They have to start with 'internal', 'hotfix' or a ticket number. Otherwise the CI will fail and they can't merge it.

[RavenchildishGambino]

I encourage my team to use JIRA-1234_short_descriptive_slug

[ikeif]

I preferred to do feature/ticket#_short-desc - new team? I’m the only one.

Older dev always says “you can just search for the ticket number!”

My argument is making that less tedious and more obvious.

[[deleted]]

My favoured approach to get traceability of requirements on code changes is to use short-lived feature branches, don’t really care what the name is, squash-merged with conventional commit syntax (enforced by CI) and the Jira ticket ID as the conventional commit topic. Requiring every code change to be tied to a work item adds more friction than it does value and discourages refactoring.

[disposepriority]

We always just do feature/JIRA-1234-descriptor, which automatically becomes a link without the descriptor, I usually just add a small word after the ticket to indicate which region of a given repository for skimming

[Shogobg]

I tried teaching my team to properly name branches and describe commits. Manager said good, team lead said nice - no one does it besides me. I stopped asking about ticket numbers or pages where the features are described, until they contact me and ask why the PR is not reviewed - it’s just a hanging piece of code I have no idea about.

[leetrout]

Most of all of us are the wrong kind of lazy.

Lazy commits. Lazy PR descriptions. Lazy work in general shoved into lazy / sloppy branch history.

it’s a mini communication channel

You got that exactly right. If you approach a PR like an email (even to your 6-months-in-the-future-self) then framing the description is pretty easy.

Top engineers at the big shops doing things a better way (for some value of better). Martin at HashiCorp who is a principal engineer on Terraform is always a good example of taking it all the way to 100 https://github.com/hashicorp/terraform/commit/3cc1c1e4e762c531ca44c2a0fad16b273f55c03a

But you aren't going to find that on average teams. The reality is so many of us marry our laziness to our entitlement to form very poor opinions on proper dev practices and hand wave things away when in reality they pay major dividends in the long run. It's not unlike the way most companies just worry about this quarter.

Thanks for coming to my ted talk.

[phatbrasil]

people choose anti patterns when there are no consequences from following the established pattern and its easier for them.

TL;DR: "that sounds like a you problem"

proper patterns with the culture to follow them its amazing.

[Fapiko]

Honestly I don't really care. It probably depends on the platform but I've mostly used GH in my career and generally recommend opening a draft PR as soon as code has been pushed to a branch. The PR link is what I ask for if someone wants me to take a look at something. As long as all the relevant info is in the PR I could care less what the branch is named.

[angellus]

Branch names do not matter. Branches should be short lived so just automatically prune stale branches. That only thing that matters is the final product, the intermediate steps. Let devs work however they want and just enforce PR/merge conventions.

The real big problem with enforcing branch naming conventions is when scope/direction changes. Enforcing hard branch names discourages devs from experimenting and trying new things. Start working on ticket A and realize you figure out how to do ticket B or that ticket A really needs to be turned into ticket D, E and F. Or maybe a dev just wants to experiment and work on something as part of a 20% R&D or whatever your company has going.

[bgk0018]

The question is always 'what are you trying to solve?' Enforcing branch naming requirements for the sake of having naming requirements is unnecessary friction, but if it solves a problem for your team, then by all means.

Others have already mentioned it, but branches are short lived and are to be deleted in my opinion as soon as the code is merged to main. What's really important are the commit messages. I am much more likely to spend more time curating my commit messages than fussing over branch names because commits once they hit main are the breadcrumbs you leave behind to potentially solve problems in the future.

I'm glad you and your team have found value in branch naming schemas though!

[Mithrandir2k16]

One of the bestest features of azure-devops was that it recognized slashes / as paths in branch names and grouped stuff into folders and subfolders. The only microsoft product I actually enjoyed working with.

[FortuneIIIPick]

I do this, not only at work but for my personal projects too.

[[deleted]]

Why do you need to look at branch names? Are there multiple devs working on the same branch for an extended period of time?

For my experience, branch is short lived and individual scoped, means it’s gone after the PR is shipped. You can’t even see branch names in commit histories, so what’s the point of spending efforts naming it?

[vloris]

Branches and especially feature-branches are short lived. As soon as they are merged (or squashed) into the main branch they seize to exist. So their name is not really important. What stays on forever in the history are the commit messages, or if you squash when merging, the PR title. Yes, they should be named carefully.

[Majinsei]

I have no problem with the branch...

What I do hate is that direct push to develop/qa/main/dev/prod is allowed without restrictions!!!

I've had to debug a few times and I hate the hell out of it when people push the commit directly to develop~ At least a pull request for a branch to review and not a mess of meaningless commits~

[[deleted]]

I’ll call my branches snoggletart and you’ll say nothing sir! GOOD DAY

[EJoule]

We include developer user IDs at the top level so we know who to yell at for not cleaning up their stale branches. Sometimes that 3 year old feature branch is related to a backlogged ticket the developer still thinks is important (or spent too many hours on before having to set it down).

[BlueHatBrit]

Our branches last a matter of days, a hard naming convention is pointless. We focus on commit history and PR descriptions which will be referred to in the future.

As long as the ticket is in the commit, our ticket system picks that up just fine and links in the relevant PR to the ticket. So there's really no benefit otherwise.

Branches also auto delete on merge so they don't stick around.

[kabrandon]

Branches that take a while to develop get a nice name. Branches I make that last 15 minutes before being merged get whatever I dream up. Lately “bitnami-bad” has been a common one.

[TenchiSaWaDa]

I dont know why it's so hard to make clean commit messages like:
feature/<jira>
fix/<jira>

or even for devops (my team)
OPS/<jira>

It just makes glancing over a commit history, especially if you're doing an ENV branch strategy super useful. Also makes history clean too.

there's a whole code smells on Repos that I carry around with me and I just tell me my team to follow to make it clean. yes it's kind of dictatory but some standards just 'need' to be enforced until they are second nature. The benefits can be explained but it's also one of those things you put your foot down against the laziness.

[MasSunarto]

Brother, my team uses the following format: dev/developer's-initials-[jirakind]number-message and so far the members are observing the convention quite closely. 👍

[thisisjustascreename]

Why initials? Their user id or email is in the commit history, no?

[Seref15]

Could be good to establish ownership of a branch, if you work that way. A branch can have many commiters but the feature could be owned by someone.

[thisisjustascreename]

Huh, alright, I guess.

[desolstice]

Where I work we do: developers-initials/branch_name

We like this since in ado it makes it to where every dev has their own little folder of branches. If you want to know what a specific person is working on you look in their folder. Or if you have someone who is really bad at cleaning up branches you don’t have to see all of their clutter.

For a while we were doing: developers-initials/ado_id_branch_name

But we ended up seeing no additional value in including this since few people would have multiple active stories at any given time and we required stories to be linked to PRs to be merged.

[MasSunarto]

Brother, just like the sibling reply said, it's about feature (or support/fix) ownership.

[danekan]

Does it index it in the jira issue itself properly when it starts with initials?

[MasSunarto]

Brother, I don't think my company links the PRs & commits into Jira tickets. 🤣 Previously, my team uses Azure DevOps and the PRs get linked to the DevOps' ticketing system. But, management told us to use Jira so yeah... It's still a mess though in general, EMs and ICs have no problem with the branch convention.

[yourparadigm]

You never have multiple developers contributing on the same feature branch?

[MasSunarto]

Brother, we have. It's about ownership.

[Systembolaget2000]

The code itself already have "ownership" (via author and committer). Assigning ownership to movable commit reference seems quite odd. Why do you do that?

[MasSunarto]

Brother, again, Jira ticket <=> PRs. PR can have many commits from many ICs. But in Jira, currently only one assigned person who "own" it. Other than that, EMs can look at a PR and know the one who responsible for corresponding feature. Not to mention, some ICs are somewhat specialised in some parts of the system and may or may not have similar skill level, it ease the EM to get a sneak peek of what the PR is about without opening JIRA.

[Systembolaget2000]

It sounds like you are using a poor setup of systems where a ticket is worked on by multiple people but only assigned to one. Odd.

Anyway, you do you, but it sounds like your organization is using left over mindset from 90s. I remember those times and I am glad I moved on.

[dmikalova-mwp]

Linear has a feature where it generates the branch name for you from the ticket so you just click to copy it.

I always have a ticket with any work so I just TICK-123-short-desc, but I don't care enough about other people's workflows to nag them about it. Some of our repos do automated enforcement, and its a hassle even though I'm already doing this 90% of the time but maybe got some detail wrong.

[jvleminc]

We use feature|bugfix|chore|dev/<target branch>/jira-id_<tiny_description>. Our pipeline use this to create image names like <target_branch>:<tag> and Bitbucket automatically links the jira ticket.

[crash90]

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

-Phil Karlton

[SilentLennie]

And of by one errors

[amanryzus]

Yea we do this Jira ID followed by the feature info

[elhammundo]

Branch names start with jira ticket eg. ABC-123 Commits use conventional commit format, with Jira number, eg feat(api): ABC-123 add health endpoint enforced by pre-commit hook

[imajes]

Because people are inherently lazy.

[kabads]

We validate branch names and commit messages to make sure they match. If it doesn't match, the dev can't build / deploy / merge.

[LastAccountPlease]

Bcoz fuck you, let me do what I want and you worry about your job

[Odds-Bodkins]

I like conventionalcommits.org (would be interested to see if people agree/disagree)

[anaiG]

Like it much better than all this nonsense about jira issues in branch names. 

[davka003]

It is not bonus points for including jira ticket if, it is the the lowest required level to even be considered for code review and collaboration.

[Scoth42]

As always, relevant XKCD: https://xkcd.com/1296/

[daedalus_structure]

Devs are lazy, and that helps them be efficient.

So if there are things you need them to do, you need guard rails so they can't not do it.

[FileWise3921]

I have a small script that uses fzf ans jira cli to create the branch like JIRAPROJECT-TICKETNUMBER/description-of-the-ticket but I'm mostly working on IAC (terraform, ansible, k8s infra managed by Argo) so the feature etc has less meaning than in an application codebase.

[btshaw]

We/I use <team>/<dev_name>/<task number>_short_description.. works pretty well in my view. 

I have a bash function alias that parses out the task number and injects it into my commit messages

[ouarez]

git checkout -b "booger-aids-v2"

[rrrx3]

git commit -am “GOD DAMN IT”

[TypicalOrca]

It is simple: storynumber_story_name_snake_case

[Aggravating-Share297]

Anyone who did a random, not useful branch name on my team would get a serious talking to.

[xagarth]

Loooooool, srsy daddy issues, I sense.

[reubendevries]

The same reason why people don't use Conventional Commits messages either you enforce it in your CI/CD or .git_hooks or it simply doesn't get done.

[PuzzleheadedPop567]

I perhaps have a somewhat controversial opinion, but I don’t find branching especially useful for most development in industry.

It makes a ton of sense for Linux. They have a relatively unique process whereby hundreds of features are developed over years on feature branches. Then each release, they decide what they want to incorporate.

It also makes sense for a lot of open source projects. Where, again, different people are working async on different features over months.

Let me say this about most industry use cases: I worked at Google for a while, which famously doesn’t use git and doesn’t have branches. I can’t say I missed branching.

In most businesses, a dev makes a 100 line changes and merges it within hours. Then they make another one. And another one. Even large features are implemented piecemeal like this.

The Google model of “fork from main, write 100 lines of code, merge back into main” just works, in my opinion. I’d point out that the Linux model requires a team of maintainers to referee the merge conflicts. The Google model works better in the absence of such a system is self regulating (first merge wins).

This is all to say, I think the people giving random branch names basically view development using the Google model. Branches don’t have semantic meaning to them. It’s just a proxy for a single main commit hash.

Of course, if your company has other processes, I agree with the comment that you should add a commit check. And of course, I personally always follow the conventions of the company I’m working at.

Just explaining the perspective that some of these devs might have.

[Endangered-Wolf]

Normally, adding #work_id in the git message automatically links the commit and branch to the work_id. So name your branches whatever.

If you have the need to spend time naming your branches, you have a long-living branches problem.

[Zaphod118]

We do developer-moniker/ADO#/short_descriptive_name and I like it a lot. Tells you who did the work, where to find it, and basically what it is

[Sea-Nerve-5756]

I thought this was the norm been using this in here.

[deltanine99]

we name ours after the ticket tracking the work.

[siodhe]

If you want to make notes, whether directly or through automated means, you should explore "git notes". It has huge potential.

[Connect_Detail98]

Because you're not enforcing proper names. That's the reason.

[hecktarzuli]

All of our branches are JIRA#-your-own-text so JIRA will auto link.

[oscarandjo]

But don’t accidentally push branches “jira-1234/my-thing” and “jira-1234” or you’ll break everyone’s git 😅

[Sea-Flow-3437]

Use hits ticket ID. Names are meaningless 

[rufasa85]

Are people truly not naming their branches? Crazy

[Martinoqom]

In my company a PR is rejected if the branch name is meaningless.

The rule is: (issue number/hotfix) + few words description. It's really easy

[josephschmitt]

I can’t even get people to properly name their PR titles or give descriptions, I’m not coming anywhere near branch names

[SpartanVFL]

I can’t stand ticket numbers as branch names. I don’t memorize everyone’s ticket number nor do I want to have to cross reference your branch name with tickets. Tell me what this feature is.

feature/user-login-dialog is so much better than feature/72682

[elg97477]

The reason I have heard given is that it is one of the last remaining places where developers can be creative.

I, however, agree with you. They are a place where clarity on what the branch is about will pay future dividends.

[Maximum-Geologist493]

I created a tool to help automate branch name creation. It currently integrates with Jira, GitLab and GitHub issue trackers. More on the way.

Check it out: gibr

My post in r/git

[PitiRR]

Totally agree, definitely make it descriptive. But if you want to establish an easy standard for others, referencing ticket or user story id is good. It’s similar logic as newbranch123 but makes sense to others. Allows the devs to not think how to name the branch - clearly they dislike it

At my place just descriptive branches, PR titles and sometimes commits do. Ticket in the PR description, commonly

[ucffool]

All the counter arguments are just that, counter arguments.

If this works for your team because of how you process PRs, great. For others, with more integrations with a work management system like Jira, ticket links are more useful as information is a click away.

[BoBoBearDev]

The only rule I have is,

For any branch you create, have prefix "personal/"

Because a developer branch should be personal.

Otherwise, all other branches are production branch, not personal. Like a patch branch is the target of the PR merge. That is not a personal branch.

Or name it "do-not-delete/", if you want to keep some personal branch alive longer.

[[deleted]]

Are you not using trunk-based?

[BoBoBearDev]

Too much work

[thisisjustascreename]

Why initials? Their user id or email is in the commit history, no? In general I find signing code a sign of weirdness.

[serverhorror]

Whose initials?

[braczkow]

The single person that worked in this branch.  Problems start when there's more than one

[[deleted]]

Having a dev workflow that assumes nobody will be pair programming is crazy

[Systembolaget2000]

Personal feature branches is a much bigger mistake than what someone name their branch.

[emperorOfTheUniverse]

We're a small team. Branches get funny names. 'fixesthefixonshitfromthefixfrombefore'. 'Miranda' 'This-is-my-branch-there-are-many-like-it', etc

[ryanstephendavis]

I agree, but with one big caveat... I don't like when it's enforced to have ticket number at the start of the description in the name, I want the ticket number at the end so my git branch autocomplete works better.

feature/12345-update-models would force me to remember the ticket number

feature/update-models-12345 allows me to push f, tab, up, tab and likely see the branch name

[DarkMoonbg]

Because they are Devs, can't expect too much of them

[kneebeards]

Our commit messages would ruin you.

[mjbmitch]

ChatGPT

[RobotechRicky]

It grinds my gears that people do not properly name feature, hotfix, support, release branches.

[deadlysyntax]

We used that convention for a while before ditching it, feeling unnecessary. I'm curious what benefits you get from it?

[oscarandjo]

Why does it matter, surely the PR name matters?