Regarding feature branches...
In most of the open source projects I've worked on with a central repository there seems to be a system of patch review so that all contributions get an extra pair of eyes. We deliberately opted *out* of that for these early stages of development, because we thought that would slow us down. I think that was a good decision. But I think that there may be potential in using git to find a middle ground that ties the review procedure more closely to the version control system, and less to the issue tracking system. That's vague, I know. Really, I'm just very curious to see what we come up with in terms of development process. I hope this is an area that we all feel confident expressing our opinions on, because we have a lot of expertise on open source process and discipline among us, but how to adapt those processes and discipline to git is still an open question for the world at this point. 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
