On Tue, May 21, 2013 at 10:59:17AM +1000, Quilkey, Tony wrote: > I am looking at formulating and then documenting our vcs workflow > using Git at work. I have an idea of how I want things to work, but am > a little hazy on some of the details. > > Our basic workflow will be based around: > http://nvie.com/posts/a-successful-git-branching-model, with a few > exceptions. > > We would like to create our release-* branches from the last release > tag. From there, we would like the ability to cherry pick (or take the > complete diff) commits from the develop branch. > > So, we are after is: > > 1) Create topic (feature) branches from develop, and merge back into > develop when complete. > > 2) Once it is decided we are packaging a release, make a release-* > branch from the previous release tag. > > 3) Cherry pick/merge/whatever any commits we want from develop into > the new release-* until it is complete. > > 4) Merge the new release-* branch into master and tag it. > > Repeat as necessary. > > At the moment I am a little stuck on how exactly we can cherry pick > stuff from develop into a release-* branch. I'm not even sure this > approach is exactly what we should be doing.
Having been involved in a couple of projects that use cherry-pick like this, I strongly advise against doing this. It makes it much harder than it needs to be to find out which branches contain a particular commit. The workflow described in the URL above does the more sensible thing of periodically merging the release branch(es) back into master (or develop). This is similar to the workflow Junio uses to develop Git itself, which is described in gitworkflows(7). The idea is to start your topic branch from the oldest release to which a bugfix must be applied, then merge it into the appropriate release branches. Then you merge this branch upwards into the later release branches and your development branch. So your development branch always contains all release branches (not just similar commits, but the *same* commits so that each release branch tip is an ancestor of the development branch's tip). This means that you can use "git branch --contains" or "git describe --contains" to answer the question "which release(s) contain this commit?", whereas with cherry picking there is no easy and reliable way to do so. > Our main concern is that at this stage, there is no guarantee that all > commits within develop can be pulled into a release. One advantage of starting a bugfix topic branch from the oldest release it applies to is that you are developing and testing that fix on the release code. If it doesn't apply cleanly to the development branch then you fix the conflict when merging. Of course you may start a bugfix branch from the wrong place, in which case you would have to cherry pick the commits back to an older branch, but this should be a rare occurrence and will sort itself out as you merge the fix upwards. > In regards to how we can achieve the above results any input would be > much appreciated. Or if there are any other better options available, > I'm all ears. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
