[nicksantamaria]

    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.

[Tomte]

Yes, that's very unconvincing.

He may think that he is rebasing later anyway, but sorting all those commits into "need for my feature" vs. "don't need for my feature", followed by the rebasing within the feature certainly takes much longer than the split second of creating a branch and keeping those features separate from the beginning.

It's great if it works for him, but he's certainly not saving time.

[dionian]

Yeah, maybe if the project is super small and you can memorize everything about it. but this doesn't scale to many real-world size projects very well

[drchopchop]

git checkout -b new_feature_branch is an onerous workflow?

[Cthulhu_]

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. You end up having to switch to various branches to fix the reviews.

But that's really not that big of a deal. The context switch is worse than the git checkout call.

[the8472]

git worktree[0] can help with working on multiple branches at once, especially if your workflow involves having a bunch of uncomitted changes. You could also stash them, but if there are more complex things like submodules, ignored build artifacts and so on you don't want to mess with then worktrees are a good alternative.

[0] https://git-scm.com/docs/git-worktree

[dkersten]

> 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

Sure, but its not like the different changes just don’t exist if you use only master, branches are a way of managing them separately and only merging when you are ready, if you don’t use branches, you have to have some other way to manage this. If you don’t, and its not a problem, then you could also just not work on three branches at once.

[malingo]

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.

[iainmerrick]

But you’ll also have to rebuild. If your build system is bad, that could be slow. If your build system is really bad, you might need a clean build.

All build systems (that people actually use) are really bad.

[alunchbox]

Is it? Simple solution setup a an alias _git cob new_feature_ which can fill in the rest. Takes a second or two to write.

[mrunkel]

gco -b new_feature_branch for me.