Here is an overview of the single repo (side A) option. There is a central repository for all workshops [1]: https://github.com/swcarpentry/workshop The “master” branch has the current state-of-the-art content. If we can't agree on that, there may be a handful of feature branches with alternative content. A developer preparing for a new workshop should create a per-workshop branch from the master: $ git checkout -b 2012-12-my-workshop master and optionally merge the feature branches they like: $ git merge git-wtk They adjust the index page to include only the content subdirectories that they are interested in, and then they build their workshop website and publish it somewhere [2]. They may, at their discretion, push their branch back into the master repository (to show other instructors what they're up to during development). After the workshop is over, they should push their branch back into the master, tag the branch tip, and delete their branch. Instructors can use the past-workshop tags and pending-workshop branches to get a feel for the material that other instructors are teaching [3]. Workshop-specific changes go into the new per-workshop branch. General changes go into feature branches which should be merged into the master branch (possibly via GitHub pull requests) and into your own per-workshop branch. If you don't like changing branches, poke a SWC dev to cherry-pick general changes into a feature branch for you. [1]: There's a mock-up at https://github.com/wking/swc-workshop [2]: The tools used to build the website (and thus the format of the index page) are outside the scope of this proposal. The example [1] uses Jekyll (the gh-pages default) to build the websites, and publishes the per-workshop sites: http://wking.github.com/swc-workshop/ http://wking.github.com/swc-workshop/master/Readme.html http://wking.github.com/swc-workshop/2012-10-caltech/ http://wking.github.com/swc-workshop/2012-10-lbl/ … as submodules of the master gh-pages branch: https://github.com/wking/swc-workshop/tree/gh-pages [3]: I think this paragraph is the only real developer-workflow difference between the single-repo model and the multi-repo model.