{"thread":{"id":"28349","subject":"Branching strategies","startedAt":"2011-09-09T23:01:11Z","lastAt":"2011-09-20T00:12:47Z","messageCount":5,"participants":["robert mena","Andrew Ardill","Jakub Narebski","gitlist"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"175250","messageId":"CAAZ43xaFzJWzPsqhP0QDRTP0Ea-dMpCpr1vDiujFFn94j+SRCQ@mail.gmail.com","threadId":"28349","inReplyTo":null,"subject":"Branching strategies","fromName":"robert mena","fromEmail":"robert.mena@gmail.com","sentAt":"2011-09-09T23:01:11Z","receivedAt":"2011-09-09T23:01:11Z","isPatch":false,"sender":{"key":"robert.mena@gmail.com","avatar":null},"body":"Hi,\n\nI have a project where I have to do a continuous integration, adding\nfeatures/making changes on a daily basis. Some changes are one liners\nwith no functionality just, for example, textual changes or a new\nbutton. Some are actual features or bug fixes.\n\nSo today my developers do their business and publish the changes in a\nbeta site where the customer or the qa takes a look. The problem is\na standard one. Sometimes features stay already developed (waiting\nfor review) for a long time and other changes/features get approved\nfirst.\n\nSince some of those can touch the same files how can I make this a\nlittle bit better (manageable)?\n\nI am considering doing feature branches. The customer requests to\nadd feature A I open a bug tracking issue and create a branch 1276\ncorresponding to the bug id.\n\nIn my simply view I'd have a master/live branch and every time I need\nto create a new branch I do it from here. When the developer is happy\nhe merges his branch with a beta branch where the Q&A/customer review\nis done.\n\nWhen this review gets an OK he merges his feature branch with the live\none, redo the tests and publish.\n\nI'd really appreciate feedback for this specially for the weak points\nand known problems of my approach with alternatives :)\n\nRegards.\n"},{"id":"175255","messageId":"CAH5451kn5WD4+S3_SGMarGyoUs6NA6Xvz9Pb8Wdpt9v0nY+Uow@mail.gmail.com","threadId":"28349","inReplyTo":"CAAZ43xaFzJWzPsqhP0QDRTP0Ea-dMpCpr1vDiujFFn94j+SRCQ@mail.gmail.com","subject":"Re: Branching strategies","fromName":"Andrew Ardill","fromEmail":"andrew.ardill@gmail.com","sentAt":"2011-09-10T01:18:51Z","receivedAt":"2011-09-10T01:18:51Z","isPatch":false,"sender":{"key":"andrew.ardill@gmail.com","avatar":"https://gravatar.com/avatar/da14cb7c091dd44dc6c63a4d3361b149acaf25226dc78eb4131a17b93d9b0993?d=mp&s=160"},"body":"On 10 September 2011 09:01, robert mena wrote:\n> Hi,\n>\n> I have a project where I have to do a continuous integration, adding\n> features/making changes on a daily basis.  Some changes are one liners\n> with no functionality just, for example, textual changes or a new\n> button.   Some are actual features or bug fixes.\n>\n> So today my developers do their business and publish the changes in a\n> beta site where the customer or the qa takes a look.  The problem is\n> a standard one.  Sometimes features stay already developed (waiting\n> for review) for a long time and other changes/features get approved\n> first.\n>\n> Since some of those can touch the same files how can I make this a\n> little bit better (manageable)?\n>\n> I am considering doing feature branches.   The customer requests to\n> add feature A I open a bug tracking issue and create a branch 1276\n> corresponding to the bug id.\n>\n> In my simply view I'd have a master/live branch and every time I need\n> to create a new branch I do it from here.  When the developer is happy\n> he merges his branch with a beta branch where the Q&A/customer review\n> is done.\n>\n> When this review gets an OK he merges his feature branch with the live\n> one, redo the tests and publish.\n>\n> I'd really appreciate feedback for this specially for the weak points\n> and known problems of my approach with alternatives :)\n>\nA very interesting read is\nhttp://nvie.com/posts/a-successful-git-branching-model/\n\nIt may not be perfect for you, however it does discuss some very\ninteresting issues, particularly how workflow is just as important as\nthe branching model.\n\nAnother interesting read is the maintainer's notes from the git\nproject. The branching strategy is a little different then the\nprevious one, and will perhaps give you a better understanding of the\npracticalities of such a strategy. They normally can be found at\nhttps://git.wiki.kernel.org/index.php/MaintNotes but kernel.org is\ndown at the moment so try\nhttp://code.google.com/p/git-mirror/source/browse/MaintNotes?name=todo\nYou can also look at\nhttp://git-blame.blogspot.com/p/note-from-maintainer.html and in the\nsource repository at Documentation/howto/maintain-git.txt\n\nHope that helps a little.\n\nRegards,\nAndrew\n"},{"id":"175570","messageId":"m3ty8errkd.fsf@localhost.localdomain","threadId":"28349","inReplyTo":"CAAZ43xaFzJWzPsqhP0QDRTP0Ea-dMpCpr1vDiujFFn94j+SRCQ@mail.gmail.com","subject":"Re: Branching strategies","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2011-09-15T11:07:03Z","receivedAt":"2011-09-15T11:07:03Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"robert mena writes:\n\n> I have a project where I have to do a continuous integration, adding\n> features/making changes on a daily basis. Some changes are one liners\n> with no functionality just, for example, textual changes or a new\n> button. Some are actual features or bug fixes.\n> \n> So today my developers do their business and publish the changes in a\n> beta site where the customer or the qa takes a look. The problem is\n> a standard one. Sometimes features stay already developed (waiting\n> for review) for a long time and other changes/features get approved\n> first.\n> \n> Since some of those can touch the same files how can I make this a\n> little bit better (manageable)?\n> \n> I am considering doing feature branches. The customer requests to\n> add feature A I open a bug tracking issue and create a branch 1276\n> corresponding to the bug id.\n> \n> In my simply view I'd have a master/live branch and every time I need\n> to create a new branch I do it from here. When the developer is happy\n> he merges his branch with a beta branch where the Q&A/customer review\n> is done.\n> \n> When this review gets an OK he merges his feature branch with the live\n> one, redo the tests and publish.\n> \n> I'd really appreciate feedback for this specially for the weak points\n> and known problems of my approach with alternatives :)\n\nThe \"Version Control by Example\" by Eric Sink, http://www.ericsink.com/vcbe/\ncontains chapter about workflows, including feature branch workflow.\n\nJunio Hamano blog (the old version) included a few articles about\nusing feature-branch workflow too.\n\nHTH.\n-- \nJakub Narębski\n"},{"id":"175799","messageId":"4E778F15.9050705@myword.co.uk","threadId":"28349","inReplyTo":"CAH5451kn5WD4+S3_SGMarGyoUs6NA6Xvz9Pb8Wdpt9v0nY+Uow@mail.gmail.com","subject":"Re: Branching strategies","fromName":"gitlist","fromEmail":"gitlist@myword.co.uk","sentAt":"2011-09-19T18:51:01Z","receivedAt":"2011-09-19T18:51:01Z","isPatch":false,"sender":{"key":"gitlist@myword.co.uk","avatar":null},"body":"On 10/09/2011 02:18, Andrew Ardill wrote:\n> On 10 September 2011 09:01, robert mena wrote:\n>> Hi,\n>>\n>> \n>> Since some of those can touch the same files how can I make this a\n>> little bit better (manageable)?\n>>\n\n> A very interesting read is\n> http://nvie.com/posts/a-successful-git-branching-model/\n>\n> It may not be perfect for you, however it does discuss some very\n> interesting issues, particularly how workflow is just as important as\n> the branching model.\n\n\nI came across the nvie post some time and it was very useful, but it \ndoesn't address handling of feature branches, especially where there is \noverlap.\n\nI have a website where people can register. They can also buy things. If \nthey haven't registered when they come to checkout, the checkout process \nincludes registration. Users can also create \"sponsorship\" pages where \nthey ask friends to sponsor them in a marathon etc. If someone setting \nup a sponsorship page is not already registered, it's included in the \nprocess.\n\nSo there are three strands (to avoid using the word \"branch\") - \nregistration, buying, and sponsorship - which end up affecting the same \nbits of code. Registration was done a year ago but recently needed \nupdating; buying was started some months ago but got held up; \nsponsorship started recently, has been completed, and has \"overtaken\" \nbuying.\n\nHow should I use branches in this scenario? Or if I've got the concept \nwrong, how should I change my workflow?\n\nThanks\n\nRoddie Grant\n"},{"id":"175827","messageId":"CAH5451kOS2d5J_iHxi_SDxHW0rDY4Xxd3JgBSgV-o_tETQjgQw@mail.gmail.com","threadId":"28349","inReplyTo":"4E778F15.9050705@myword.co.uk","subject":"Re: Branching strategies","fromName":"Andrew Ardill","fromEmail":"andrew.ardill@gmail.com","sentAt":"2011-09-20T00:12:47Z","receivedAt":"2011-09-20T00:12:47Z","isPatch":false,"sender":{"key":"andrew.ardill@gmail.com","avatar":"https://gravatar.com/avatar/da14cb7c091dd44dc6c63a4d3361b149acaf25226dc78eb4131a17b93d9b0993?d=mp&s=160"},"body":"On 20 September 2011 04:51, gitlist wrote:\n>> A very interesting read is\n>> http://nvie.com/posts/a-successful-git-branching-model/\n>>\n>> It may not be perfect for you, however it does discuss some very\n>> interesting issues, particularly how workflow is just as important as\n>> the branching model.\n>\n>\n> I came across the nvie post some time and it was very useful, but it doesn't\n> address handling of feature branches, especially where there is overlap.\n>\n> I have a website where people can register. They can also buy things. If\n> they haven't registered when they come to checkout, the checkout process\n> includes registration. Users can also create \"sponsorship\" pages where they\n> ask friends to sponsor them in a marathon etc. If someone setting up a\n> sponsorship page is not already registered, it's included in the process.\n>\n> So there are three strands (to avoid using the word \"branch\") -\n> registration, buying, and sponsorship - which end up affecting the same bits\n> of code. Registration was done a year ago but recently needed updating;\n> buying was started some months ago but got held up; sponsorship started\n> recently, has been completed, and has \"overtaken\" buying.\n>\n> How should I use branches in this scenario? Or if I've got the concept\n> wrong, how should I change my workflow?\n>\n> Thanks\n>\n> Roddie Grant\n\nThe concept of 'feature branches' apply primarily to development.They\nallow you to build individual features for your system independently\nof one another, and concurrently. Further, they provide a history of\ncommits that detail the effort that went in to creating that feature.\n\nOnce the feature is completed however, typically it will get merged\nwith a given release of the system. If further work is to be done on\nthat feature, either a new feature branch is created for the\n'improvement', or a similar hot-fix/bug-fix branch is created. When\nthat work is done it gets merged either back on to the same release or\ninto a future release.\n\nThese feature branches do not host the separate functionality of the\nsystem, but instead reveal the history of their development. I have\nnot heard of any intelligent way to use just an SCM to partition and\nkeep separate the different functional aspects of a system; developing\nmodules is generally achieved by writing modular code.\n\nIf you do have a number of modules you can track each of them\nindividually. Write version-dependencies into the modules, and you can\ndevelop on them individually, updating them to depend on the latest\nversion as appropriate.\n\nIf you are not using well separated modules, and the development of\neach 'thread' affects the same 'core' files, you need to migrate\nchanges to these core files between threads when appropriate. For\nexample, if you are working on the sponsorship thread, and develop a\npaypal integration that you now want to include in the buying thread\n(and can't continue developing it until you do), you should identify\nthe commits that entail that change and merge them into the buying\nthread branch. Better than retrospectively trying to dig out features\nand bug-fixes, however, is ensuring a clean separation of thread code\nand core code. Thankfully, since git has such good merging ability,\nyou can often merge a feature branch which is miles behind the latest\nrelease and it will slot in flawlessly.\n\nThere are many different aspects to this sort of work, but the best\nthing to do is to keep the future in mind, and try to do things that\nwill make life easier down the track. The great thing about git is\nthat it offers many tools that make things easier later on even when\nyou didn't plan for them - but that is no excuse for poor planning!\n\nHope that helps somewhat,\nAndrew\n"}]}