4 ms·
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 prim
by r1cka 11mo ago
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 11mo agoYes, please just name the branch after the ticket/issue number so we can all get the context for it and call it a day
- wara23arish 11mo agoI 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 11mo agogibr makes it easy to do this and in a consistent manner
- 6LLvveMx2koXfwn 11mo agowe do: [feature/bug]/ISSUE-NUMBER-summary-of-issue e.g.: bug/psi-456-broken-args-parsing
- darkwater 11mo agoMore or less the same here, but we (I?) prefix it with the username as well, so when pulling branches you know who created it.
- celticninja 11mo agoBut the PR and git blame can tell you this so I would never look at the Branch name to find out this information
- darkwater 11mo agoFor me is useful when I run 'git fetch' from the command line. I don't use any graphical git client
- dewey 11mo agoA nice benefit of prefixing by your-name/issue-1234-some-description is that many git clients will show it in a folder structure that way and it's easy to differentiate yours from other branches.
- ytreister 11mo agoI added a new TODO issue so that username can be configured in the branch name. gibr currently does not have support for username. https://github.com/ytreister/gibr/issues/42 https://github.com/ytreister/gibr/issues/42
- ytreister 11mo agoI implemented this in version 0.6.0 which was just released. https://github.com/ytreister/gibr/releases/tag/0.6.0 https://github.com/ytreister/gibr/releases/tag/0.6.0 The issue assignee can be used in the branch name.
- ytreister 11mo agogibr makes it super easy to do exactly this!
- jjgreen 11mo agoI've worked in a couple of places with <issue ID>-<something descriptive> conventions, moderately useful
- krferriter 11mo agoYes, `issue-10-add-feature-X` style is best.
- bavent 11mo agoI have a little script that does this automatically - lists out Jira tickets assigned to me, then when I select one, creates a branch with the ticket number and the title, subbing hyphens for spaces and truncating if needed. It’s handy for when I want to list branches, I can filter on keywords I remember from the ticket name.
- johntash 11mo agoThat's been my preference at most places I've worked. issue id so the branch gets linked to jira or whatever and a short description to find the branch later if needed.
- jasonjmcghee 11mo agoThis. 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.
- dewey 11mo agoThis is probably my favorite Linear feature. 1) Cmd + shift + . -> Copy branch name 2) Build feature on that branch name 3) Build / Merge on Github and Linear closes the issue
- ytreister 11mo agoThat is what gibr does, it helps you do this with ease
- aizk 11mo agoGreat point
- alkonaut 11mo agohaving 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 11mo agoEither 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 11mo agoI understand, but that means you need to review the commits and code changes and do not have the context which could be found either in the issue title, description, etc.
- ytreister 11mo agoExactly, 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 11mo agoCorrect, I use uuids as branch names, to the chagrin of my teammates
- brettgriffin 11mo agoThis 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 11mo agoWhy would you do this!!!!!
- focom 11mo agoCommit message should be ephemeral too. Squashing after a PR should be the default. Only at that moment does the PR/Commit message matter.
- bavent 11mo agoHard 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.
- freedomben 11mo agoFully agree with you here. Blunt squashing is a bandaid to the problem of lazy commits. Commits should IMHO be specific and atomic. Like fixing one bug or implementing one feature. Obviously there are cases where this ideal isn't practical, but the answer is still not squash everything, it's to think for 10 more seconds about the commit and do your best.
- bavent 11mo agoYeah, I think over use of GitHub, which seems to encourage squash-merging, has led to this where a lot of people I’ve seen treat a PR as essentially one commit - because it ends up being one in the end. If you keep your PRs small I guess the end result is the same, but even then I like things in individual commits for ease of review.
- danielbln 11mo agoI want to see detailed atomic commits during PR review, and once it's reviewed I'm happy to have it squashed. If the PR produces so much code/changes that main branch needs detailed atomic commits for future reference, then the PR was too large to begin with, imo.