41–48 of 48 posts
No time spent creating new branches for new features. No time spent switching between branches to address feedback. I'm sorry but these are non-issues with git. The approach you've outlined makes collaboration on features impossible. Cherry-picking and rebasing does not scale for either teams, or lots of parallel workstreams.
git checkout -b new_feature_branch is an onerous workflow?
Way way more organized to use branches.
Earlier quoted context omitted.
Switching branches does get a bit annoying if you happen to work in multiple branches simultaneously and have to switch halfway through a task, or there's a lot of differences; however, that is also a matter of organization. It's happened to me though; one scenario is that you created a couple of merge requests for the same repo over the course of a day, and the next day feedback from code review or testing comes in.…
Git checkout understands "hyphen expansion" for your previous branch (a la `cd -` to switch to your previous working directory), so switching between two branches is as easy as `git checkout -` or even `git co -` if you have an alias.
All build systems (that people actually use) are really bad.
The git advice works for either experts or small projects. If you’re an expert, choose your own workflow. I find in large projects with many users, branches help to recover quickly from mistakes and help define testing history. My primary concern is for novices to go at it without branches because they’re hard to deeply understand without experience and they see experts managing without.
Learn how to use rock climbing equipment before you rely on it. Experts, do whatever works best for you!
He seems to be implying that it's OK to rebase against master and/or force push the remote ref, as long as the only person you are pleasing is yourself.
I mean, a lot of people progress in their Git knowledge until they reach the point where they want to minimize the clutter of merge commits. That's almost a cliche.
But how you do that when you are working with others, some of whom may have advanced Git knowledge while others are complete novices, that's what the real world looks like.
Seems like all the time you'd ostensibly save on not branching you instead spend doing very careful munging later and crafting very careful commits with git add -p and rebase and other equally time consuming tools. I don't see the value-add at all.
I mean, I already do this, because I like to be able to understand my commits as standalone historical artifacts. IMHO commits exist to be read (by your future self trying to figure out WTF you were on about most of all!) as much as they exist to change the state of the codebase.
Given that I'm already doing this, it wouldn't be any more work to use a workflow like this, I guess? (I still use branches. And have multiple git worktrees checked out at once from the same repo.)