Hey guys, now that Andreas has at least familiarized himself with git enough to get some changes into the new github repository, it seems like a good time to start discussing how to manage our branches. In SVN there is a pretty common structure:
trunk - crazy new stuff gets added here branches - when you need to do development with a bit of protection from the wild firehose that is trunk, you copy trunk into a subfolder here. copies are cheap in svn, do this as much as you like. pulling in changes from trunk is doable, but kind of a pain tags - when you have an interesting version of trunk or a branch you copy it here with a descriptive name and then agree never to change it again. In git there are lots of possibilities. Right now we are kind of ignoring them and just have everyone pushing changes to the master branch as they make them. We could use branches really heavily, we could even give each developer his own repository, whatever, git will mostly keep track of stuff as long as you don't edit history after publishing it. I'm not necessarily opposed to the "firehose" approach, but my personal preferences tend toward using "feature branches" with a bit heavier review before updating master, and trying to keep the master branch in the public repository "ready to release," or at least not totally broken. Here's an article on a really structured git approach that I thought was pretty interesting: http://nvie.com/git-model . It is probably on the extreme end of isolating work into separate branches. What do you all think? -- David Winslow OpenGeo - http://opengeo.org/
