Just that by far the most common branch setup in git repos seems to be using master as the "dev trunk", with releases, release candidates (etc) on special branches. There are often additional feature branches for even more speculative changes, but master is generally not really "safe," even if it's not the most dangerous branch.
So master tends to be a sort of "middle" state (between release/release-candidate branches and speculative feature branches), stuff that is slated for the next release, and has received review -- but may still have some bugs to be shaken out. For complicated long-term changes, people often do development on special feature branches, but smaller and more straight-forward changes generally get put into master directly. Master branches break with some regularity. If you're familiar with gcc's subversion repo setup, it's pretty similar to this (with the subversion trunk being "master") Git's own repo actually does this too. Thanks, -miles -- Cat is power. Cat is peace.
