{"id":915,"date":"2010-06-07T09:12:48","date_gmt":"2010-06-07T16:12:48","guid":{"rendered":"https:\/\/simpleprogrammer.com\/?p=915"},"modified":"2018-04-13T12:21:00","modified_gmt":"2018-04-13T16:21:00","slug":"simple-branching-strategy-part-2-implementation","status":"publish","type":"post","link":"https:\/\/simpleprogrammer.com\/simple-branching-strategy-part-2-implementation\/","title":{"rendered":"Simple Branching Strategy Part 2: Implementation"},"content":{"rendered":"

In my previous post<\/a>, I talked about the idea of having a simple branching strategy and why I prefer one where everyone works off the same branch.\\n\\nIn this post I will show you how to create what I believe is the most simple and effective branching strategy.\\n\\nTake a look at this diagram of a sample project\u2019s code lines:\\n\\n\"branching<\/a>\\n\\n<\/p>\n

Walking through it<\/h2>\n

\\n\\nThe idea here is very simple.\u00a0 Let’s walk through a development cycle together:\\n\\n<\/p>\n

    \\n <\/p>\n
  1. Development starts.\u00a0 Everyone works off of trunk.\u00a0 Code is frequently checked into trunk, many developers checking in code 3-4 times a day, as they complete small quality sections of development.<\/li>\n

    \\n <\/p>\n

  2. The continuous build server is continuously building and checking the quality of the code every single time code is checked in.\u00a0 Any integration problems are immediately fixed.<\/li>\n

    \\n <\/p>\n

  3. Enough features are done to create a release.\u00a0 Trunk is tagged for release and a release 1 branch is created representing the currently release production code.<\/li>\n

    \\n <\/p>\n

  4. Developers continue to work on trunk not being interrupted by the release.<\/li>\n

    \\n <\/p>\n

  5. A customer finds a high priority issue in Release 1.<\/li>\n

    \\n <\/p>\n

  6. A Rel 1 Hot Fix branch is created, branched off of Release 1 to fix the high priority issue.\u00a0 It turns out that a good fix will take some time.\u00a0 Team decides the best course of action is to apply a temporary fix for now.<\/li>\n

    \\n <\/p>\n

  7. Rel 1 Hot Fix is done and merged back into Release 1 branch.\u00a0 Release 1 is re-deployed to production.<\/li>\n

    \\n <\/p>\n

  8. In the meantime another emergency problem shows up that must be fixed before the next release.\u00a0 Rel 1 Hot Fix 2 branch is created.<\/li>\n

    \\n <\/p>\n

  9. The bug fix for Rel 1 Hot Fix 2 is a good fix which we want in all future releases.\u00a0 Rel 1 Hot Fix 2 branch is merged back to Release 1 branch, and merged back to trunk.\u00a0 Release 1 is redeployed.<\/li>\n

    \\n <\/p>\n

  10. In the meantime work has been going on on trunk, team is ready for Release 2.<\/li>\n

    \\n <\/p>\n

  11. Release 2 branch is created\u2026<\/li>\n

    \\n<\/ol>\n

    \\n\\n<\/p>\n

    Breaking it down<\/h2>\n

    \\n\\nI gave a pretty detailed walk-through for a very simple set of actual steps.\u00a0 But, I hope you can see how simple this process really is.\\n\\nThe basic idea here is that we are trying to decouple releases from development as much as possible.\u00a0 The team is always going to keep chugging along, building new features and enhancing the code base.\u00a0 When we decide we have enough features for a release, we simply branch off of trunk and create the release branch.\\n\\nWe can even do some testing on the release branch before we go to production if we need to without impacting future development.\\n\\nThe release branch code-lines never come back to trunk.\u00a0 They don\u2019t need to, they only exist so that we can have the exact production code and make modifications to it as hot-fixes if we need to.\\n\\nWe branch hot-fixes off of the release branch so that we can work on them independently, because not all hot-fixes go back to the main code-line.\u00a0 We can make a hot-fix just for the current release, or we can merge it back to trunk to make it a permanent fix.\\n\\nThat is all there is to it.\u00a0 This kind of branching strategy almost completely eliminates merges.\u00a0 The only merge you ever do is small merges for hot-fixes.\\n\\nYour branching strategy does not have to be complicated.\u00a0 A simple strategy like this can fit almost any software development shop.\\n\\n<\/p>\n

    Frequently disputed points<\/h2>\n

    \\n\\nAlmost immediately when I introduce this simple system someone says:\\n\\nWhat about half-completed features?\u00a0 I don\u2019t want to release half-completed features.\u00a0 Using this strategy with everyone working off trunk, you will always have half-completed features.<\/strong>\\n\\nSo what?\u00a0 How many times does a half-completed feature cause a potential problem in the system?\u00a0 If the code is quality and incrementally developed, it should not impact the rest of the system.\u00a0 If you are adding a new feature, usually the last thing you do is actually hook-up the UI to it.\u00a0 It won\u2019t hurt anything to have its back-end code released without any way to get to it.\\n\\nContinuous integration, (especially running automated functional tests), trains you to always keep the system releasable with every commit of new code.\u00a0 It really isn\u2019t hard to do this, you just have to think about it a little bit.\\n\\nIf worse comes to worst and you have a half-finished feature that makes the code releasable, you can always pull out that code on the release branch.\u00a0 (Although I would highly recommend that you try and find a way to build the feature incrementally instead.)\\n\\nIf you know you’re going to do something that will disrupt everything, like redesigning the UI, or drastically changing the architecture, then go ahead and create a separate branch for that work.\u00a0 That should be a rare event though.\\n\\nI need to be able to develop the features in isolation.\u00a0 If everyone is working off of trunk, I can\u2019t tell if what I did broke something or if it is someone else\u2019s code.\u00a0 I am impacted by someone else breaking things.<\/strong>\\n\\nGood, that is some pain you should feel.\u00a0 It hurts a lot less when you’re continuously integrating vs. working on something for a week, merging your feature and finding that everything is broken.\\n\\nIt is like eating a meal.\u00a0 All the food is going to end up in the same place anyway.\u00a0 Don\u2019t worry about mixing your mashed potatoes with your applesauce.\\n\\nIf something someone else is doing is going to break your stuff, better to fail fast<\/strong>, then to fail later.\u00a0 Let\u2019s integrate as soon as possible and fix the issue rather than waiting until we both think we are done.\\n\\nBesides that, it is good to learn to always check in clean code.\u00a0 When you break other people and they shoot you with Nerf guns and make you wear a chicken head, you are taught to test your code locally before you check it in.\\n\\n<\/p>\n

    How to be successful<\/h2>\n

    \\n\\nHow can you be successful at this simple strategy?\\n\\n<\/p>\n