Hey Matthias, Thanks for humoring me on this. It doesn't seem to me that there is any way to avoid the multi-directional merge issue, right? If we have two releases and master branch and we find a bug that needs to be fixed in the first release, we still have to do a couple of complex merges to fix it on 1.0 and 2.0 and master, right? What does that workflow look like?
J On Fri, Aug 10, 2012 at 7:35 AM, Matthias Friedrich <[email protected]> wrote: > Hi, > > I had a quick look at gitflow when I was first looking for best > practices with git. The need for a (complex) diagram and the fact > that there's a tool to support the process is a clear warning sign :) > > The upside of gitflow is that there's a nice web page you can link to. > The downside is that it's obviously geared towards website development > where you only have to maintain one version of your software. As soon > as you need to maintain more than one release line you'd have to work > outside the model. This shortcoming makes gitflow unsuitable for > product development (and Crunch is a product). > > The classic model uses a main line where development and integration > of feature branches happen. Unlike in gitflow, release branches are > long-running and stay alive as long as you support the release line > (ie. 0.3.x). If at all possible, merges happen from release branches > into the main line, so there is just one merge direction which > simplifies things. > > In gitflow, even the standard bugfix case ("hotfix") requires merging > in multiple directions. From my experience, more complex merging > patterns lead to regressions sooner or later when people forget > merges, especially when in a hurry (test cases can't help you and we > don't have a QA team to catch them). In our case it's also difficult > to gather around a whiteboard when things go wrong, so simplicity > should be key. > > Unless I really got it wrong, I think in gitflow they managed to > design a system that's both more complex and less capable than the > classic approach ;-) > > > Looking from a prospective contributor's perspective, we have two use > cases to consider: > > 1. Contribute a new feature (=> check out master) > 2. Fix a bug in, say, 0.3.0 (=> check out branch "release-0.3.x") > > Easy to explain, git novices know it from CVS or Subversion. No need > to learn a new process on top of a new revision control system. > > Regards, > Matthias > > P.S.: If you really want to dig into this, see "Streamed Lines" > by Appleton et al, for example. Careful though, this topic is among > the dullest in all software engineering. > > On Thursday, 2012-08-09, Josh Wills wrote: > > The only other serious contender to a release management process would be > > git flow, i.e., > > > > http://nvie.com/posts/a-successful-git-branching-model/ > > https://github.com/nvie/gitflow > > > > If I was to summarize the difference, I think it comes down to whether > > origin/master reflects the development work we are doing towards the next > > release, or whether it reflects the current stable release, and the > > origin/develop branch is the piece that we currently work off of. > > > > I haven't worked in either of the two paradigms, having developed > > server-based software for far too long, and I'd like a discussion on the > > pros and cons so I can visualize the consequences of each choice. > > > > J > > > > On Thu, Aug 9, 2012 at 9:52 AM, Matthias Friedrich <[email protected]> wrote: > > > > > Hi, > > > > > > next small item on my release TODO list is a little bit of software > > > configuration management: We should decide on how we want to deal > > > with branches and tags. > > > > > > I don't have much experience with git, but I'd suggest a simple model > > > that most people are already familiar with. An old blog article of > > > mine describes this [1] (it's the second strategy discussed). There > > > are more complex models (people write lengthy papers about them) but > > > I've never really needed more than this. It's important to have clear > > > conventions that don't cause headaches or require advanced tool > > > mastery. > > > > > > Maven's release plugin supports this process perfectly, but I admit I > > > haven't used it with git before (with Subversion and Mercurial it > > > worked fine). If you want to take this approach, I'd document it on a > > > wiki page and post the link here for review. > > > > > > What do you think? > > > > > > Thanks, > > > Matthias > > > > > > [1] http://blog.mafr.de/2007/04/25/release-management/ > > > > > > > > > > > -- > > Director of Data Science > > Cloudera <http://www.cloudera.com> > > Twitter: @josh_wills <http://twitter.com/josh_wills> > -- Director of Data Science Cloudera <http://www.cloudera.com> Twitter: @josh_wills <http://twitter.com/josh_wills>
