{"thread":{"id":"35465","subject":"Branching workflow","startedAt":"2013-12-03T18:06:20Z","lastAt":"2014-09-25T05:15:57Z","messageCount":7,"participants":["Javier Domingo","John Keeping","Junio C Hamano","Javier Domingo Cansino"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"231440","messageId":"CALZVapnjN_69y0+PLFA2t8b72WDK+D4BhjDRnRPxU_9iX+_NuA@mail.gmail.com","threadId":"35465","inReplyTo":null,"subject":"Branching workflow","fromName":"Javier Domingo","fromEmail":"javierdo1@gmail.com","sentAt":"2013-12-03T18:06:20Z","receivedAt":"2013-12-03T18:06:20Z","isPatch":false,"sender":{"key":"javierdo1@gmail.com","avatar":"https://gravatar.com/avatar/0f43d4d2e5f4320e8b5e1a46914213c5459dd0de261ab1587f222827f863d727?d=mp&s=160"},"body":"Hi,\n\nI have been using a very basic workflow for branching, features each\nin a branch.\n\nMy branches would be:\n- develop <= Main upstream branch\n- feature/* fix/*  <= Feature and fix branches\n- master <= Integration of the whole feature and fix branches\n\nSo I have now came up with a very difficult task. I just discovered\nthat one of those branches, lest call it feature/bad, is evil and is\nmaking the integration branch (master) fail horribly.\n\nIn my workflow, I tend to merge develop (official updates) into my\nfeature branches, and them into master.\n\nSo now I have the big problem on how to undo all changes from\nfeature/fix. I have been told that one alternative workflow would be\nto revert the last merge and remerge it into master, so that I have\nalways just one commit to revert if necessary (instead of the\nmonstrous quantity I have now to).\n\nThe workflow proposal should be in order of importance:\n- Let me stay up-to-date with develop branch\n- Easy to revert in master\n- Have a clean history\n- Easy to follow\n\nI think I should be capable of doing some sort of merge/rebase\nbranching workflow to avoid having to do that. I have thought about\nrebasing always the feature branches, and rebasing master into all of\nthem, but it seems pretty strange to me.\n\nIf anyone can give any advice, I would fully appreciate!\n\nJavier Domingo Cansino\n"},{"id":"231447","messageId":"20131203184250.GB3163@serenity.lan","threadId":"35465","inReplyTo":"CALZVapnjN_69y0+PLFA2t8b72WDK+D4BhjDRnRPxU_9iX+_NuA@mail.gmail.com","subject":"Re: Branching workflow","fromName":"John Keeping","fromEmail":"john@keeping.me.uk","sentAt":"2013-12-03T18:42:50Z","receivedAt":"2013-12-03T18:42:50Z","isPatch":false,"sender":{"key":"john@keeping.me.uk","avatar":"https://avatars.githubusercontent.com/u/1702081?v=4"},"body":"On Tue, Dec 03, 2013 at 07:06:20PM +0100, Javier Domingo wrote:\n> I have been using a very basic workflow for branching, features each\n> in a branch.\n> \n> My branches would be:\n> - develop <= Main upstream branch\n> - feature/* fix/*  <= Feature and fix branches\n> - master <= Integration of the whole feature and fix branches\n> \n> So I have now came up with a very difficult task. I just discovered\n> that one of those branches, lest call it feature/bad, is evil and is\n> making the integration branch (master) fail horribly.\n> \n> In my workflow, I tend to merge develop (official updates) into my\n> feature branches, and them into master.\n> \n> So now I have the big problem on how to undo all changes from\n> feature/fix. I have been told that one alternative workflow would be\n> to revert the last merge and remerge it into master, so that I have\n> always just one commit to revert if necessary (instead of the\n> monstrous quantity I have now to).\n> \n> The workflow proposal should be in order of importance:\n> - Let me stay up-to-date with develop branch\n> - Easy to revert in master\n> - Have a clean history\n> - Easy to follow\n> \n> I think I should be capable of doing some sort of merge/rebase\n> branching workflow to avoid having to do that. I have thought about\n> rebasing always the feature branches, and rebasing master into all of\n> them, but it seems pretty strange to me.\n> \n> If anyone can give any advice, I would fully appreciate!\n\nIt sounds like you want a throwaway integration branch.  This is similar\nto the workflow Junio uses with git.git's \"pu\" branch, which involves\nrebuilding a branch by:\n\n    * resetting it to some base (\"develop\" in your case)\n    * merging in the required feature branches\n\nThis may not quite be what you want because it does mean that you cannot\nbuild on the integration branch - it is intended to be rewritten often,\nbut it does provide a good platform for testing features and then\nmerging them to a stable branch once they have proved to be good.\n\nThe advantage is that you know that the integration merges are temporary\nand you can test on top of that without having set the result in stone.\n\n<shameless plug>If you are interested in such a workflow then you may\nwant to try my git-integration program [1] to manage integration\nbranches.\n\nThere is also a reimplementation in Ruby with a slightly different\nfeature set [2]\n\n[1] http://johnkeeping.github.io/git-integration\n[2] http://github.com/felipec/git-reintegrate\n"},{"id":"231453","messageId":"CALZVapk9bD7TWGbru8VJhjV_=BYJKhTfHG7Z5hiFpzz-d4BwCQ@mail.gmail.com","threadId":"35465","inReplyTo":"20131203184250.GB3163@serenity.lan","subject":"Re: Branching workflow","fromName":"Javier Domingo","fromEmail":"javierdo1@gmail.com","sentAt":"2013-12-03T19:10:02Z","receivedAt":"2013-12-03T19:10:02Z","isPatch":false,"sender":{"key":"javierdo1@gmail.com","avatar":"https://gravatar.com/avatar/0f43d4d2e5f4320e8b5e1a46914213c5459dd0de261ab1587f222827f863d727?d=mp&s=160"},"body":"Hi John!,\n\nThanks a lot for your tip, but I have the problem that I would need to\nhave a linear history in master (forgot to mention it explicitly) ;(\n\nI build on master branch, and getting to a previous version is hereby needed.\n\nI had thought about the revert workflow, but using --no-commit. I\nwould then have a way to mark stuff as re-mergeable.\n\nI am pretty lost with this. Is like a non-ending hell, because I have\nto provide linear history to master and develop, and allowing master\nto be revertable.\n\nIsn't there something like git revert <branch-name> so that all\ncommits that have been merged from that branch, and don't belong to\nany other, can be reverted?\n\nWith this history:\nA<-B<-C := develop\nB<-D<-Z<-Y := feature/bad\nB<-D<-G<-H := feature/good\nA<-B<-C<-z<-g<-y<-h := master\n\n(caps original commits, regular merged commits)\n\nso that:\ngit checkout master\ngit revert feature/bad\n\nwould revert z and h in master history, in one single commit, and\nmaking available merging feature/bad when it's ready, with all\nconflicting if needed.\n\nIdeas welcome =)\nJavier Domingo Cansino\n\n\n2013/12/3 John Keeping <john@keeping.me.uk>:\n> On Tue, Dec 03, 2013 at 07:06:20PM +0100, Javier Domingo wrote:\n>> I have been using a very basic workflow for branching, features each\n>> in a branch.\n>>\n>> My branches would be:\n>> - develop <= Main upstream branch\n>> - feature/* fix/*  <= Feature and fix branches\n>> - master <= Integration of the whole feature and fix branches\n>>\n>> So I have now came up with a very difficult task. I just discovered\n>> that one of those branches, lest call it feature/bad, is evil and is\n>> making the integration branch (master) fail horribly.\n>>\n>> In my workflow, I tend to merge develop (official updates) into my\n>> feature branches, and them into master.\n>>\n>> So now I have the big problem on how to undo all changes from\n>> feature/fix. I have been told that one alternative workflow would be\n>> to revert the last merge and remerge it into master, so that I have\n>> always just one commit to revert if necessary (instead of the\n>> monstrous quantity I have now to).\n>>\n>> The workflow proposal should be in order of importance:\n>> - Let me stay up-to-date with develop branch\n>> - Easy to revert in master\n>> - Have a clean history\n>> - Easy to follow\n>>\n>> I think I should be capable of doing some sort of merge/rebase\n>> branching workflow to avoid having to do that. I have thought about\n>> rebasing always the feature branches, and rebasing master into all of\n>> them, but it seems pretty strange to me.\n>>\n>> If anyone can give any advice, I would fully appreciate!\n>\n> It sounds like you want a throwaway integration branch.  This is similar\n> to the workflow Junio uses with git.git's \"pu\" branch, which involves\n> rebuilding a branch by:\n>\n>     * resetting it to some base (\"develop\" in your case)\n>     * merging in the required feature branches\n>\n> This may not quite be what you want because it does mean that you cannot\n> build on the integration branch - it is intended to be rewritten often,\n> but it does provide a good platform for testing features and then\n> merging them to a stable branch once they have proved to be good.\n>\n> The advantage is that you know that the integration merges are temporary\n> and you can test on top of that without having set the result in stone.\n>\n> <shameless plug>If you are interested in such a workflow then you may\n> want to try my git-integration program [1] to manage integration\n> branches.\n>\n> There is also a reimplementation in Ruby with a slightly different\n> feature set [2]\n>\n> [1] http://johnkeeping.github.io/git-integration\n> [2] http://github.com/felipec/git-reintegrate\n"},{"id":"231454","messageId":"xmqq8uw1oij6.fsf@gitster.dls.corp.google.com","threadId":"35465","inReplyTo":"CALZVapnjN_69y0+PLFA2t8b72WDK+D4BhjDRnRPxU_9iX+_NuA@mail.gmail.com","subject":"Re: Branching workflow","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2013-12-03T19:12:45Z","receivedAt":"2013-12-03T19:12:45Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Javier Domingo <javierdo1@gmail.com> writes:\n\n               \n> Hi,\n>\n> I have been using a very basic workflow for branching, features each\n> in a branch.\n>\n> My branches would be:\n> - develop <= Main upstream branch\n> - feature/* fix/*  <= Feature and fix branches\n> - master <= Integration of the whole feature and fix branches\n>\n> So I have now came up with a very difficult task. I just discovered\n> that one of those branches, lest call it feature/bad, is evil and is\n> making the integration branch (master) fail horribly.\n>\n> In my workflow, I tend to merge develop (official updates) into my\n> feature branches, and them into master.\n\nI think the standard advice is not to contaminate feature branches\nwith unrelated changes, whether from an upstream updates or from\nother unrelated feature breanches.\n\nYou would still want to make sure that your feature branches in\nwork-in-progress state would work with updated upstream from time to\ntime, but that is much better done by having a test integration\nbranch you maintain with:\n\n    : always start from the tip of upstream\n    $ git fetch upstream\n    $ git checkout -B develop remotes/upstream/master\n\n    : merge everything you want\n    $ git merge feature/A\n    $ git merge feature/B\n    ...\n    $ git merge fix/Z\n\nAnd you will never merge 'develop' into 'master'.  Only after you\nare satisfied with a single feature (or fix), you merge that to\n'master', while your other features may still be suspect.\n"},{"id":"231456","messageId":"CALZVapkvVNxb-jJssZqjT-Y8sApK8O1pe3xTB8guNtx9Md2W6Q@mail.gmail.com","threadId":"35465","inReplyTo":"xmqq8uw1oij6.fsf@gitster.dls.corp.google.com","subject":"Re: Branching workflow","fromName":"Javier Domingo","fromEmail":"javierdo1@gmail.com","sentAt":"2013-12-03T19:25:02Z","receivedAt":"2013-12-03T19:25:02Z","isPatch":false,"sender":{"key":"javierdo1@gmail.com","avatar":"https://gravatar.com/avatar/0f43d4d2e5f4320e8b5e1a46914213c5459dd0de261ab1587f222827f863d727?d=mp&s=160"},"body":"I will start to rebase all feature branches because I have no real\ndependency on those, but master needs to have a linear history, as I\nbuild from it regularly, and I need to assure that people can get a\nprevious version of master.\n\nThe problem with that is that I wouldn't be able to have a linear\nhistory on master. I had also thought about doing a snapshot branch of\nthe integration branch, so that I could maintain history of\nintegration, and just update it with integration snapshots, but I am\ntrying to get another more git-ish way to achieve all these\nrequirements of all branches (they are really driving me crazy).\n\nThanks a lot for the idea. I will mantain clean feature branches from now on,\n\nJavier Domingo Cansino\n"},{"id":"249738","messageId":"CALZVapmm3=zgx4xZegieSxiUOcYcz9DMHVFknA8SeeYwO5fVJQ@mail.gmail.com","threadId":"35465","inReplyTo":"CALZVapkvVNxb-jJssZqjT-Y8sApK8O1pe3xTB8guNtx9Md2W6Q@mail.gmail.com","subject":"Re: Branching workflow","fromName":"Javier Domingo Cansino","fromEmail":"javierdo1@gmail.com","sentAt":"2014-09-22T15:59:02Z","receivedAt":"2014-09-22T15:59:02Z","isPatch":false,"sender":{"key":"javierdo1@gmail.com","avatar":"https://gravatar.com/avatar/0f43d4d2e5f4320e8b5e1a46914213c5459dd0de261ab1587f222827f863d727?d=mp&s=160"},"body":"Hello!,\n\nI have been using this workflow you suggested, and I happen to find it\nreally good fitting in many projects I am.\n\nI would like to seek for a little more advice. I keep rebasing all my\nwork each time master branch is updated, and I would like to know if\nthis is usually done or not.\n\nThe workflow is not using emails, but each developer has his clone\nwhere he works, and occasionally sends work to the gerrit tool we use,\nupgrading the patch with each master update.\n\nI know this is a crazy workflow, and I would like to know when you\nusually consider to update the sent patch with a rebase.\n\nCheers,\n\n-- \nJavier Domingo Cansino\n"},{"id":"249842","messageId":"xmqqsijgb7qq.fsf@gitster.dls.corp.google.com","threadId":"35465","inReplyTo":"CALZVapmm3=zgx4xZegieSxiUOcYcz9DMHVFknA8SeeYwO5fVJQ@mail.gmail.com","subject":"Re: Branching workflow","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2014-09-25T05:15:57Z","receivedAt":"2014-09-25T05:15:57Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Javier Domingo Cansino <javierdo1@gmail.com> writes:\n\n> I would like to seek for a little more advice. I keep rebasing all my\n> work each time master branch is updated, and I would like to know if\n> this is usually done or not.\n>\n> The workflow is not using emails, but each developer has his clone\n> where he works, and occasionally sends work to the gerrit tool we use,\n> upgrading the patch with each master update.\n>\n> I know this is a crazy workflow, and I would like to know when you\n> usually consider to update the sent patch with a rebase.\n\nWhen a rerolled set of patches come, I try to apply them to the same\ncommit as the previous fork point.  When there is no reroll, there\nis no reason to ever do any rebase myself.\n\nThe trial integration branch 'pu' is rebuilt from scratch every day,\nstarting from the tip of 'master' and merging all the topics that\nhave not been merged to 'master'.\n\nBy not doing unnecessary rebase, we won't risk breaking each topic.\nBy merging topics together to updated 'master', we make sure changes\ndone in other topics do not negatively affect each topic.\n"}]}