[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.