Thus git checkout -b makes perfect sense. Does it? Pull and then merge is a common operation; it gets a top-level command. Create a new branch from the one I'm

Thus git checkout -b makes perfect sense. Does it? Pull and then merge is a common operation; it gets a top-level command. Create a new branch from the one I'm working on and check it out is a common operation; it gets a flag on an existing command. What logical, coherent process decides that in each case? Branches have only one meaning in git! Hence the "forces end users to do so". There are two very common ways people use branches: one is as a temporary place to do a quick bugfix, the other is as a long-lived place to do a major rewrite or refactoring. With respect to the history of the codebase, these have very different implications, but semantically are the same type of thing in git. To pick on Subversion: when you had a long-lived branch in SVN, sooner or later you'd merge it back into the mainline... and then what happens? You want someone to be able to look at the repository and see that something major happened here and easily watch the progress, but you also want a way to say "this is done and merged". This required inventing a convention to indicate that -- in SVN, typically the finished branches would go in an "attic" directory. In git you face the same problem: making a temporary branch, doing the work, merging and then deleting the branch is what you're supposed to do in git. But for those long-lived major branches, you need to invent a convention (commonly, tagging the merge point) to indicate that they're done. I mentioned Mercurial because it has two different concepts for these things: the ephemeral deleted-once-it's-done line is a bookmark (which is pretty much exactly equivalent to a git branch, in that it's a named head that moves as you commit), and the long-lived major branch is... a branch. Which has additional semantics to indicate things like being finished. This means that in Mercurial you don't have to invent and re-invent ad-hoc conventions to handle common development patterns, while in git you do. Can't gitk do this? Every time I say I want to see two branches side-by-side without invoking the VCS, someone says "well, here's a tool that invokes the VCS to do that!" Which shows a lack of reading comprehension. Some folks need to branch differently than others. Sure, but why isn't there a clearly-documented "most projects will get along fine with this" workflow? Or, rather, why are there dozens of them? We've had VCS tools for long enough that the best practices for common cases are out there. The github workflow might be a little tricky, but as has been pointed out there are other workflows possible in git. Oh, there are. But git + GitHub has been relentlessly hyped as an Oatmeal-ish fantasy of unicorns farting rainbows onto a field of lollipops, so that's how people actually end up using it, and so it's valid to mention that it's a more complex workflow for contributors since it is a very common case and becoming more common.