{"thread":{"id":"33881","subject":"Workflow Help","startedAt":"2013-05-21T00:59:17Z","lastAt":"2013-05-21T13:49:23Z","messageCount":4,"participants":["Quilkey, Tony","John Keeping","Magnus Bäck","Andreas Ericsson"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"218026","messageId":"CAMATmi3bU7hrD-YLY1iVXbekxOx_XZfZ5yYNBfzV_VFSc_W5jw@mail.gmail.com","threadId":"33881","inReplyTo":null,"subject":"Workflow Help","fromName":"Quilkey, Tony","fromEmail":"trq@thorpesystems.com","sentAt":"2013-05-21T00:59:17Z","receivedAt":"2013-05-21T00:59:17Z","isPatch":false,"sender":{"key":"trq@thorpesystems.com","avatar":null},"body":"Hi,\n\nI am looking at formulating and then documenting our vcs workflow\nusing Git at work. I have an idea of how I want things to work, but am\na little hazy on some of the details.\n\nOur basic workflow will be based around:\nhttp://nvie.com/posts/a-successful-git-branching-model, with a few\nexceptions.\n\nWe would like to create our release-* branches from the last release\ntag. From there, we would like the ability to cherry pick (or take the\ncomplete diff) commits from the develop branch.\n\nSo, we are after is:\n\n1) Create topic (feature) branches from develop, and merge back into\ndevelop when complete.\n\n2) Once it is decided we are packaging a release, make a release-*\nbranch from the previous release tag.\n\n3) Cherry pick/merge/whatever any commits we want from develop into\nthe new release-* until it is complete.\n\n4) Merge the new release-* branch into master and tag it.\n\nRepeat as necessary.\n\nAt the moment I am a little stuck on how exactly we can cherry pick\nstuff from develop into a release-* branch. I'm not even sure this\napproach is exactly what we should be doing.\n\nOur main concern is that at this stage, there is no guarantee that all\ncommits within develop can be pulled into a release.\n\nIn regards to how we can achieve the above results any input would be\nmuch appreciated. Or if there are any other better options available,\nI'm all ears.\n\nThanks,\n\nTony Quilkey\n"},{"id":"218041","messageId":"20130521092314.GO27005@serenity.lan","threadId":"33881","inReplyTo":"CAMATmi3bU7hrD-YLY1iVXbekxOx_XZfZ5yYNBfzV_VFSc_W5jw@mail.gmail.com","subject":"Re: Workflow Help","fromName":"John Keeping","fromEmail":"john@keeping.me.uk","sentAt":"2013-05-21T09:23:14Z","receivedAt":"2013-05-21T09:23:14Z","isPatch":false,"sender":{"key":"john@keeping.me.uk","avatar":"https://avatars.githubusercontent.com/u/1702081?v=4"},"body":"On Tue, May 21, 2013 at 10:59:17AM +1000, Quilkey, Tony wrote:\n> I am looking at formulating and then documenting our vcs workflow\n> using Git at work. I have an idea of how I want things to work, but am\n> a little hazy on some of the details.\n> \n> Our basic workflow will be based around:\n> http://nvie.com/posts/a-successful-git-branching-model, with a few\n> exceptions.\n> \n> We would like to create our release-* branches from the last release\n> tag. From there, we would like the ability to cherry pick (or take the\n> complete diff) commits from the develop branch.\n>\n> So, we are after is:\n> \n> 1) Create topic (feature) branches from develop, and merge back into\n> develop when complete.\n> \n> 2) Once it is decided we are packaging a release, make a release-*\n> branch from the previous release tag.\n> \n> 3) Cherry pick/merge/whatever any commits we want from develop into\n> the new release-* until it is complete.\n> \n> 4) Merge the new release-* branch into master and tag it.\n> \n> Repeat as necessary.\n> \n> At the moment I am a little stuck on how exactly we can cherry pick\n> stuff from develop into a release-* branch. I'm not even sure this\n> approach is exactly what we should be doing.\n\nHaving been involved in a couple of projects that use cherry-pick like\nthis, I strongly advise against doing this. It makes it much harder\nthan it needs to be to find out which branches contain a particular\ncommit.\n\nThe workflow described in the URL above does the more sensible thing of\nperiodically merging the release branch(es) back into master (or\ndevelop). This is similar to the workflow Junio uses to develop Git\nitself, which is described in gitworkflows(7).\n\nThe idea is to start your topic branch from the oldest release to which\na bugfix must be applied, then merge it into the appropriate release\nbranches. Then you merge this branch upwards into the later release\nbranches and your development branch. So your development branch always\ncontains all release branches (not just similar commits, but the *same*\ncommits so that each release branch tip is an ancestor of the\ndevelopment branch's tip).\n\nThis means that you can use \"git branch --contains\" or \"git describe\n--contains\" to answer the question \"which release(s) contain this\ncommit?\", whereas with cherry picking there is no easy and reliable way\nto do so.\n\n> Our main concern is that at this stage, there is no guarantee that all\n> commits within develop can be pulled into a release.\n\nOne advantage of starting a bugfix topic branch from the oldest release\nit applies to is that you are developing and testing that fix on the\nrelease code. If it doesn't apply cleanly to the development branch\nthen you fix the conflict when merging.\n\nOf course you may start a bugfix branch from the wrong place, in which\ncase you would have to cherry pick the commits back to an older branch,\nbut this should be a rare occurrence and will sort itself out as you\nmerge the fix upwards.\n\n> In regards to how we can achieve the above results any input would be\n> much appreciated. Or if there are any other better options available,\n> I'm all ears.\n"},{"id":"218047","messageId":"20130521130748.GA634@google.com","threadId":"33881","inReplyTo":"CAMATmi3bU7hrD-YLY1iVXbekxOx_XZfZ5yYNBfzV_VFSc_W5jw@mail.gmail.com","subject":"Re: Workflow Help","fromName":"Magnus Bäck","fromEmail":"baeck@google.com","sentAt":"2013-05-21T13:07:50Z","receivedAt":"2013-05-21T13:07:50Z","isPatch":false,"sender":{"key":"baeck@google.com","avatar":null},"body":"On Monday, May 20, 2013 at 20:59 EDT,\n \"Quilkey, Tony\" wrote:\n\n> I am looking at formulating and then documenting our vcs workflow\n> using Git at work. I have an idea of how I want things to work, but am\n> a little hazy on some of the details.\n> \n> Our basic workflow will be based around:\n> http://nvie.com/posts/a-successful-git-branching-model, with a few\n> exceptions.\n> \n> We would like to create our release-* branches from the last release\n> tag. From there, we would like the ability to cherry pick (or take the\n> complete diff) commits from the develop branch.\n\nIt would probably be easier to comment on your proposal if you motivated\nwhy you want to diverge.\n\n> So, we are after is:\n> \n> 1) Create topic (feature) branches from develop, and merge back into\n> develop when complete.\n> \n> 2) Once it is decided we are packaging a release, make a release-*\n> branch from the previous release tag.\n> \n> 3) Cherry pick/merge/whatever any commits we want from develop into\n> the new release-* until it is complete.\n\nThe point of having a release branch is typically to slow down the\ndevelopment pace and reduce risk by only adding changes that you\nreally need. By starting the branch for release N+1 from the branch\nfor release N it seems you have three ways forward:\n\n - Cherrypick a small number of commits from develop. That'll give you\n release N+0.1 rather than N+1.\n - Cherrypick many (if not most) commits from develop. That might give\n you a real release, but with a lot of work. Who should select which\n commits to cherrypick? How do you keep track of dependencies? Why\n would you want to move from a known state (develop, where people\n spend most of their time) to an unknown state?\n - Merge from develop to the release branch. What's the benefit\n compared to cutting the release branch directly from develop?\n\nAs another poster has pointed out, with merging instead of cherrypicking\nthe standard Git tools will be able to do a better job at helping you\ntrack which corrections are made where.\n\n[...]\n\n-- \nMagnus Bäck\nbaeck@google.com\n"},{"id":"218048","messageId":"519B7B63.3080304@op5.se","threadId":"33881","inReplyTo":"CAMATmi3bU7hrD-YLY1iVXbekxOx_XZfZ5yYNBfzV_VFSc_W5jw@mail.gmail.com","subject":"Re: Workflow Help","fromName":"Andreas Ericsson","fromEmail":"ae@op5.se","sentAt":"2013-05-21T13:49:23Z","receivedAt":"2013-05-21T13:49:23Z","isPatch":false,"sender":{"key":"ae@op5.se","avatar":"https://gravatar.com/avatar/426e89595c75a8f5252dd0c989e5fabe5bcac616e68557427ad9aef6b0ca342a?d=mp&s=160"},"body":"On 2013-05-21 02:59, Quilkey, Tony wrote:\n> Hi,\n>\n> I am looking at formulating and then documenting our vcs workflow\n> using Git at work. I have an idea of how I want things to work, but am\n> a little hazy on some of the details.\n>\n> Our basic workflow will be based around:\n> http://nvie.com/posts/a-successful-git-branching-model, with a few\n> exceptions.\n>\n> We would like to create our release-* branches from the last release\n> tag. From there, we would like the ability to cherry pick (or take the\n> complete diff) commits from the develop branch.\n>\n> So, we are after is:\n>\n> 1) Create topic (feature) branches from develop, and merge back into\n> develop when complete.\n>\n> 2) Once it is decided we are packaging a release, make a release-*\n> branch from the previous release tag.\n>\n> 3) Cherry pick/merge/whatever any commits we want from develop into\n> the new release-* until it is complete.\n>\n\nThis will drive you crazy. If you have any sort of tempo on development\nand separate your commits into small series, it will be close to\nimpossible to track all related changes. I know, as some colleagues\ntried it not long ago.\n\n\nA better workflow is to use topic-branches for pretty much everything.\nIf the branch is mainly a bugfix, although the bug has to be fixed by\nrefactoring or remodeling something, it gets merged to whatever \"maint\"\nbranch you have (in your case I'd imagine that would be \"release-X\"\nsomething). Then you merge the release-branch into develop and take\nthe other topics directly into develop.\n\n\nWe do something like this:\n\n* work, work, work (mostly on master)\n* cut a release by setting a tag and creating a maint-branch for it\n (actually, it's a beta-release that goes off to QA, but whatever)\n* maint branches are 100% test-driven development\n* bugfixes (with their test-cases, as well as test-cases for other\n affected areas) go directly to maint (although possibly via a\n topic-branch if the change is bigger than trivial).\n* maint is merged to master\n* repeat as necessary\n\nIt works reasonably well and ensures a high code quality with very\nlittle overhead. Sometimes people commit bugfixes to master by mistake.\nIn that case, we simply cherry-pick the fix to 'maint' and then merge\nmaint back to master as usual.\n\nIt does require some sort of stability between projects and the libs\nshipped by and used by the project though, but assuming you haven't\ndone things horribly wrong at the design stage, this model should work\nreasonably well while avoiding the whole \"where are the bugfixes and\nin which order do I need to apply them?\" issue.\n\n-- \nAndreas Ericsson andreas.ericsson@op5.se\nOP5 AB www.op5.se\nTel: +46 8-230225 Fax: +46 8-230231\n\nConsidering the successes of the wars on alcohol, poverty, drugs and\nterror, I think we should give some serious thought to declaring war\non peace.\n"}]}