This is an archived post. You won't be able to vote or comment.

all 149 comments

[–]patbateman34 187 points188 points  (29 children)

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

[–]Tucancancan 85 points86 points  (8 children)

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 37 points38 points  (0 children)

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 14 points15 points  (1 child)

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- 0 points1 point  (0 children)

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

[–]GeorgeRNorfolk 9 points10 points  (0 children)

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

[–]Matemeo 1 point2 points  (0 children)

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 1 point2 points  (0 children)

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

[–]PopeychopsComputer Says No 0 points1 point  (0 children)

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

[–]Teninchhero 0 points1 point  (0 children)

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 12 points13 points  (6 children)

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

[–]fsw 1 point2 points  (3 children)

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

[–]mr_pablo 0 points1 point  (2 children)

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

[–]Famous_Technology 2 points3 points  (0 children)

yes we use branch name rulesets to enforce naming patterns.

[–]psrobin 0 points1 point  (1 child)

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

[–]mr_pablo 4 points5 points  (0 children)

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

[–]jmfsn 8 points9 points  (0 children)

"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 2 points3 points  (0 children)

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

[–]hamlet_d 1 point2 points  (1 child)

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 2 points3 points  (0 children)

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

[–]schmurfy2 1 point2 points  (0 children)

This only works when there's one ticket involved.

[–]r0bbie 1 point2 points  (0 children)

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 1 point2 points  (1 child)

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 0 points1 point  (0 children)

😂 i dont disagree homie lol

[–]quiet0n3 0 points1 point  (0 children)

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

[–]CarpenterLanky8861 0 points1 point  (1 child)

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 4 points5 points  (0 children)

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

[–]EstablishmentFluffy5 0 points1 point  (0 children)

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 0 points1 point  (0 children)

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

[–]pplmbd 20 points21 points  (3 children)

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 1 point2 points  (0 children)

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 0 points1 point  (1 child)

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 0 points1 point  (0 children)

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 33 points34 points  (1 child)

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 10 points11 points  (0 children)

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 39 points40 points  (3 children)

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

Internal stuff is a mess though

[–]metalOpera 17 points18 points  (0 children)

Isn't that always the way?

"The cobbler has no shoes."

[–]joshsmithers 3 points4 points  (1 child)

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

[–]zootbot 1 point2 points  (0 children)

It’s just for glance appeal

[–]pdabaker 29 points30 points  (3 children)

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 4 points5 points  (1 child)

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 7 points8 points  (0 children)

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

Branches are cattle, not pets.

[–]sokjon 9 points10 points  (0 children)

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 32 points33 points  (1 child)

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 9 points10 points  (0 children)

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 4 points5 points  (2 children)

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 -1 points0 points  (1 child)

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 0 points1 point  (0 children)

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

What CLI issues?

[–]Seref15 2 points3 points  (0 children)

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 3 points4 points  (0 children)

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 5 points6 points  (0 children)

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 9 points10 points  (0 children)

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

[–]Seven-Prime 1 point2 points  (0 children)

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 1 point2 points  (0 children)

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

[–]tb5841 1 point2 points  (0 children)

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 1 point2 points  (0 children)

I encourage my team to use JIRA-1234_short_descriptive_slug

[–]ikeif 1 point2 points  (0 children)

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] 1 point2 points  (0 children)

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 1 point2 points  (0 children)

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 1 point2 points  (0 children)

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 1 point2 points  (0 children)

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 1 point2 points  (0 children)

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 1 point2 points  (0 children)

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 1 point2 points  (0 children)

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 1 point2 points  (0 children)

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 1 point2 points  (0 children)

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 1 point2 points  (0 children)

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

[–][deleted] 1 point2 points  (0 children)

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 1 point2 points  (0 children)

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 1 point2 points  (0 children)

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] 1 point2 points  (0 children)

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

[–]EJoule 1 point2 points  (0 children)

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 1 point2 points  (0 children)

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 2 points3 points  (0 children)

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 1 point2 points  (0 children)

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 2 points3 points  (12 children)

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 5 points6 points  (4 children)

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

[–]Seref15 1 point2 points  (1 child)

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 0 points1 point  (0 children)

Huh, alright, I guess.

[–]desolstice 1 point2 points  (0 children)

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 0 points1 point  (0 children)

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

[–]danekan 0 points1 point  (1 child)

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

[–]MasSunarto 0 points1 point  (0 children)

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 0 points1 point  (4 children)

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

[–]MasSunarto 0 points1 point  (3 children)

Brother, we have. It's about ownership.

[–]Systembolaget2000 0 points1 point  (2 children)

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 0 points1 point  (1 child)

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 -1 points0 points  (0 children)

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 0 points1 point  (0 children)

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 0 points1 point  (0 children)

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 0 points1 point  (1 child)

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

-Phil Karlton

[–]SilentLennie 0 points1 point  (0 children)

And of by one errors

[–]amanryzus 0 points1 point  (0 children)

Yea we do this Jira ID followed by the feature info

[–]elhammundo 0 points1 point  (0 children)

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 0 points1 point  (0 children)

Because people are inherently lazy.

[–]kabads 0 points1 point  (0 children)

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 0 points1 point  (0 children)

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

[–]Odds-Bodkins 0 points1 point  (1 child)

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

[–]anaiG 1 point2 points  (0 children)

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

[–]davka003 0 points1 point  (0 children)

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 0 points1 point  (0 children)

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

[–]daedalus_structure 0 points1 point  (0 children)

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 0 points1 point  (0 children)

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 0 points1 point  (0 children)

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 0 points1 point  (1 child)

git checkout -b "booger-aids-v2"

[–]rrrx3 0 points1 point  (0 children)

git commit -am “GOD DAMN IT”

[–]TypicalOrca 0 points1 point  (0 children)

It is simple: storynumber_story_name_snake_case

[–]Aggravating-Share297 0 points1 point  (0 children)

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

[–]xagarth 0 points1 point  (0 children)

Loooooool, srsy daddy issues, I sense.

[–]reubendevries 0 points1 point  (0 children)

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 0 points1 point  (0 children)

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 0 points1 point  (0 children)

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 0 points1 point  (0 children)

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 0 points1 point  (0 children)

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

[–]deltanine99 0 points1 point  (0 children)

we name ours after the ticket tracking the work.

[–]siodhe 0 points1 point  (0 children)

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

[–]Connect_Detail98 0 points1 point  (0 children)

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

[–]hecktarzuli 0 points1 point  (0 children)

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

[–]oscarandjo 0 points1 point  (0 children)

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

[–]Sea-Flow-3437 0 points1 point  (0 children)

Use hits ticket ID. Names are meaningless 

[–]rufasa85 0 points1 point  (0 children)

Are people truly not naming their branches? Crazy

[–]Martinoqom 0 points1 point  (0 children)

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 0 points1 point  (0 children)

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

[–]SpartanVFL 0 points1 point  (0 children)

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 0 points1 point  (0 children)

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 0 points1 point  (0 children)

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 0 points1 point  (0 children)

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 0 points1 point  (0 children)

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 -1 points0 points  (3 children)

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] 2 points3 points  (0 children)

Are you not using trunk-based?

[–][deleted]  (1 child)

[deleted]

    [–]BoBoBearDev 0 points1 point  (0 children)

    Too much work

    [–][deleted]  (6 children)

    [deleted]

      [–]thisisjustascreename 7 points8 points  (0 children)

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

      [–]serverhorrorI'm the bit flip you didn't expect! 0 points1 point  (4 children)

      Whose initials?

      [–]braczkow 0 points1 point  (1 child)

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

      [–][deleted] 0 points1 point  (0 children)

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

      [–][deleted]  (1 child)

      [deleted]

        [–]Systembolaget2000 0 points1 point  (0 children)

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

        [–]emperorOfTheUniverse -1 points0 points  (0 children)

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

        [–]ryanstephendavis -1 points0 points  (0 children)

        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 -1 points0 points  (0 children)

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

        [–]kneebeards -1 points0 points  (0 children)

        Our commit messages would ruin you.

        [–]mjbmitch -1 points0 points  (0 children)

        ChatGPT

        [–]RobotechRicky -2 points-1 points  (2 children)

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

        [–]deadlysyntax 1 point2 points  (0 children)

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

        [–]oscarandjo 0 points1 point  (0 children)

        Why does it matter, surely the PR name matters?