[r1cka]

I think people worry too much about branch names. Feature branches are usually ephemeral. Prefix your branch with your personal identifier so I know who is primary on it and worry more about the commit message which will live on indefinitely.

[morkalork]

Yes, please just name the branch after the ticket/issue number so we can all get the context for it and call it a day

[jasonjmcghee]

This. Linear has the one click or shortcut to grab the generated branch name based on the ticket.

With GitHub setup properly, on PR open, it auto comments the link to the ticket and links to the pr in the ticket.

[wara23arish]

I hate issue numbers for branch names. ISSUE-9482 doesn’t really provide much.

Ticket link should always be included in PR description.

But branch names should be descriptive like terraform_dev_create_instance

etc

[ytreister]

That is what gibr does, it helps you do this with ease

[alkonaut]

having feature/username/id-desc is good though. Because at least you can identify why the branch is there. That they are ephemeral doesn't mean that people actually clean them up...

[delusional]

Either it has commits I care about or it doesn't. Either way, I'm not going to consult the branch name.

If it has commits I care about, then it stays. If it doesn't, It goes. I'm only deleting on the server afterall, people can just push it back.

[ytreister]

Exactly, people tend to leave messes. It makes it much easier to know what the branch was for and have more piece of mind when you want to delete it.

[loevborg]

Correct, I use uuids as branch names, to the chagrin of my teammates

[brettgriffin]

This would infuriate me. You have to index that guid to something yourself. Why wouldn't you at least give yourself some help (your name, issue number, type of change, area of project, etc). Why make your job harder than it needs to be?

[ytreister]

Why would you do this!!!!!

[aizk]

Great point

[focom]

Commit message should be ephemeral too. Squashing after a PR should be the default. Only at that moment does the PR/Commit message matter.

[bavent]

Hard disagree here. GitHub does encourage this sort of thing, but even there for my PRs to be easily reviewable, I like to keep my commits organized and with good messages explaining things. That way the reviewer can walk the commits, and see why each thing was thing was done.

I also like it for myself, when I’m going over my own PRs before asking for a review - I will often amend commits to ensure the work is broken down correctly, each thing that should go together, does.

In a way, stacked PRs are just a higher-level abstraction of this too - same idea, keep work that goes together in the same place.

[xorcist]

Did you mean before the PR? Why would anyone have a review system if you change the code after review?

Hopefully the commits are already squashed and rebased before review to value reviewers' time.