It troubles me that we are referring to the master branch as unstable. While we are not following the dictums of Agile methodology it is clear to me that the master branch should always be potentially releasable. It is not a dumping ground for untested features or half-complete code.
If something is incomplete, leave it in a branch. If you want to collaborate, create a github project and form a team. Only when the code is fully baked, merge it into the master. The SHA1 value of a change tracks it across all branches. No need to perform no-op merges. Simply check the branch history to see it contains the SHA1 hash you're interested in. I found the 'git show-graph' alias at http://gitready.com/intermediate/2009/01/26/text-based-graph.html to be helpful. Simply 'git show-graph | grep <sha1>' to easily find out if one change is included in a branch. If managing the releases inside one git repository seems prone to complications, create a separate repository for each release. After all, post-release there really should be only bug fixes.
