[_chris_]

I find the idea that master is the default is exactly why it should not be the development branch. For open-source software, that's what people download and try to build -- it should always strive to be production ready.

[rleigh]

People should be downloading actual releases. This could be release archives, or release tags.

Version control is not primarily for consumption of releases, it's for participation in development, and I think the branching strategy should reflect that. Having the current development state be the default branch is entirely suitable for this purpose.

I've always found the use of "develop" vs "master" quite jarring, and not even that helpful for an end user. master can change on a whim, while using actual release tags gives you something stable.

[geezerjay]

> People should be downloading actual releases. This could be release archives, or release tags.

Yes, and those versions are represented by tags created on the master branch. Github automatically interprets tags created on the master branch as being releases, and even creates nice little tar files with the branch's contents.

> master can change on a whim

Actually, it can't. According to the Git workflow, the only thing committed to the master branch is either the contents of release branches or hotfixes.

[viraptor]

You can have both. With the right tooling you can prevent direct push to master, but at the same time implement CI to which you can submit your branches to be merged to master.

This way you can develop against master, you won't push garbage into it by mistake, and you can guarantee that each (first-parent path) commit on master passes the automated tests.