There are 3 main branches:
- Experimental: This is where Alblaka (and maybe others) pur in their ideas/major code changes, the "What if?" branch. Only requirement: game must still be playable, as in "doesn't crash too often". Bug-fixes may happen but are not required.
- Development: One a feature or set of features has been accepted, it is put into the development branch. Here all bug-fixes happen and ideas/code might get improved or slightly modified (under the control of Alblaka) with the target to have a fully releasable version in the end. Requirement for all commits is to be compilable and fix bugs/improve code without introducing new bugs.
- Release: Once a development branch has been stabilized enough, it is branched out to a specific release version branch. Once this is done that version is considered released and only bug-fixes that address stability issues may happen to this branch. New features or improvements of existing features do not belong here. There is a minimum delay of 1 month per release, so not every minor change caused server admins the trouble to update.
Actually this isn't the way you should use git, you have a "master" branch which serves as your trunk (ie, all branches merge back here and all releases live here). When you wanna work on something you, as the developer check out your own copy of the repo and work on your code and then submit a pull request when you're done. The project owner (or his delegates) then have to accept the pull requests and handle any merge conflicts. When the project owner is ready to do a release, they "tag" those files in the master branch with a version number which can then be used to que jenkins or whatever build system you're doing to generate a "recommended build".
The key there is that you tag releases, not branch them. You can roll your repo back to tags just like branches but not have to deal with all of the ugly branching :).
- There should be a standardized way of submitting bugs/requests. The primary focus here is ease of use as I expect more non-technical feedback than actual coders to use it. This doesn't have to be a highly sophisticated tracking tool, even the forum could be a solution, just something that works fine for the task.
Github has a built in issue tracker.