Post #1222683
2026-04-17 00:48 UTC
Replies (10)
-
@cocoaphony@mastodon.social 2026-04-17 00:52
@isaiah@mastodon.social generally a new branch per "thing to do" (bug, new feature, experiment). Worktrees let you put these in separate directories, while still letting git manage them. And I believe in short-lived branches. I do something, merge it, delete the branch. I generally even do this when I'm working on personal projects.
-
@JonathanGerlach@mastodon.social 2026-04-17 00:56
@isaiah@mastodon.social Make a new branch for each bug. Use git to hop between branches. Delete the branch afterwards. You can probably get away with force push to rewrite a branch’s history, but as soon as you have other people, you’ll want to disable that. I use git flow, but I don’t always follow it so strictly.
-
@isaiah@mastodon.social 2026-04-17 01:01
last question: do you use git differently on your personal projects than on your corporate work?
-
@bwebster@mastodon.social 2026-04-17 01:39
@isaiah@mastodon.social Pre-Claude: I typically didn't make per bug/feature branches. Usually had two branches going, one for "next dot release" bug fixes and such, and another for whatever the longer term major release stuff I was working on. Would merge one into the other periodically when it made sense. Post-Claude: I vibe coded my own Mac app that automates creating per-issue branches and worktrees, working on each in a separate Claude session, then merging and cleaning up when each one is done.
-
@MrRooni@mastodon.social 2026-04-17 03:22
@isaiah@mastodon.social Everything in one dir, a branch for each feature or bug, merge & delete branch.
-
@nguarracino@techhub.social 2026-04-17 02:03
@isaiah@mastodon.social We can't push directly to main, so yes, new branch for each bug fix or feature. I rebase liberally on this branch since it's just for me. Generally try to do just one fix per branch unless there's another closely related fix in the same area. I delete the branch after merging or else they would just clutter things up over time. Usually switch between branches in the same directory, unless it's a big structural refactoring that would make switching difficult. I follow this for personal projects too, mostly because I'm so used to it I think.
-
@astrovore@gts.vidja.club 2026-04-17 02:12
@isaiah@mastodon.social different teams will do things different ways, but the most common pattern I've seen used is GitHub flow https://docs.github.com/en/get-started/using-github/github-flow The short version is: 1. Create a branch in your cloned copy of the repo 2. Do a single task on that branch (fix a bug, implement a feature, etc) 3. Submit the change as a Pull Request 4. Address feedback/comments on the same branch. 5. Once the branch is merged, delete it. Your next task gets its own branch. Separate copies of the repo are not required and indeed are discouraged. Use git's built-in branch management instead.
-
@arroz@mastodon.social 2026-04-17 07:31
@isaiah@mastodon.social As always, it depends. If I’m doing something and I find a related bug I usually just sneak the fix in the same branch. I often use the main work directory for work but I usually keep one or more work trees as well (one of them with the main branch of the project, or a branch rebased to it, always ready to run to be used as reference). I never delete anything. I believe tools should handle information, you shouldn’t have to delete it for this to be manageable.
-
@nilrog@mastodon.nu 2026-04-17 22:15
@isaiah@mastodon.social At work I rely 💯 on local branches for whatever I do. And I push patches to gerrit from those branches. Only one checkout and I use git to switch what I am working on. Once a patch is merged in gerrit, I delete the local branch
-
@glebd@mastodon.social 2026-04-18 01:58
@isaiah@mastodon.social I use jujutsu on top of my git repos, it’s a game changer - imagine being able to work on top of a virtual merge of multiple branches while keeping them clean and tidy https://github.com/jj-vcs/jj