Wow. That article is really excellent. Git is so powerful; it's great to see an outline of a set of constraints that both takes advantage of that power and also is comprehensible.
I think it would make sense to adopt its recommendations, or at least a subset of them that makes sense give our current quality of development. In particular, I'm +1 on keeping the 'master' branch production ready and having a 'develop' branch that is like an svn's trunk. Having a temporary release branch for each release seems like a no-brainer. I think it would make a ton of sense to transition to this over the course of the next couple months. Maybe start the 1.0 release branch once we are feature complete on the 1.0 features. On Wed, Jun 23, 2010 at 5:25 PM, David Winslow <[email protected]> wrote: > 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/ > -- Sebastian Benthall OpenGeo - http://opengeo.org
