point is if you dont do it then this workflow is useless and doesnt bring anything since stable sources are in tags
Romain Manni-Bucau @rmannibucau http://www.tomitribe.com http://rmannibucau.wordpress.com https://github.com/rmannibucau 2015-01-30 13:01 GMT+01:00 Andy Gumbrecht <agumbre...@tomitribe.com>: > Hi Mark, > > This is a great discussion and I am really starting to see both sides. Again > I am pretty neutral, but still lean to Gitflow. > > However (there is always one of those), I have to agree with Alan on the > 'cherry picking' issue. It does not tie in with the documentation at all? I > have read > https://www.atlassian.com/git/tutorials/comparing-workflows/gitflow-workflow > over and over to try and see where all this work you suggest is coming from, > and I still don't see it? > >>> Where do you see that? I keep reading that Atlasssian document and I >>> don’t see >>> where it requires cherry picking each and every commit. >>> >>> >>> You have a master branch and a development branch. All work happens on >>> the development branch but releases happen from master branch, right? So how >>> do all the commits end up on the master branch? Someone has to pick the >>> 'good' ones from the development branch over to the master branch. >>> Especially when a release comes near. >>> >>> > Releases are taken from develop - 'Once the release is ready to ship, Mary > merges it into master and develop' - This is where I cannot understand the > nature of it's / your dismissal, as it is virtually a one liner? Someone > does play the release manager at some point and all this Gitflow is just to > allow a buffer zone during it's preparation so devs can carry on oblivious > to it. > > The first picture in the mentioned docs really paints it for me. I played > out Gitflow step by step on a simple hello world repo and still can't find > 'all this work'? > > We have of course jumped ahead of the game with 1.7.x and develop branches, > because we don't have a 2.x release in master yet (ie. the only thing that > should be in master is 2.0.0-Milestone1). It is just to save a back peddle > when we finally get there. Really, as it stands today, the develop branch > 'should' be 1.7.x and 2.x should be in it's own branch until it takes over > as the main release. It would have been that way if we'd made the transition > to git earlier. > > What you suggest is, as mentioned in the thread, that we basically do it the > svn way (with the advantages of git locally). We still freeze checking in > potentially unstable stuff while the release is ongoing and collaborate via > the lists as usual. Totally cool with it if that's really what you want. I > was totally cool with svn ;-) > > Andy. > > > -- > Andy Gumbrecht > https://twitter.com/AndyGeeDe > http://www.tomitribe.com >
