Branching for code-reuse You wrote some code. Your app works. Now you want to do something slightly different. Timelines are tight. You want to give the new team enough control to get their job done. Yet you want to leverage what you've already done. "Lets create a branch of the same code for the new team", you say, "Once they are through their time crunch, lets integrate the two branches." Sounds simple. But there are three main problems with that:The time crunch never really ends. There is no time to take a break and merge.If you do find the time, you also find that the code has diverged to the point where merging becomes more expensive than maintaining multiple branches.Features are added, time goes on and re-use becomes next to impossible.You started out thinking that re-use through branching is going to have a multiplier effect to the functionality you deliver. Initially, it is. But soon, it becomes a multiplier on how much you invest into getting simple stuff done. So, what's the right way to do it? How do we avoid this? How do you get out of it? Well, there has been a lot written on code re-use. And I really don't feel like getting into that right now. It maybe a topic for another day. Today, I just wanted to say that if you're looking to branch your source code for re-use, then don't! If you really want to, then don't expect everything to be merged back. If you really really want to merge it back, then its going to cost you! Comments Vinay Belgaumkar Well, well...good to see your blog ! You need to keep writing often, though. My thoughts on branching - it really depends. If one needs multiple releases of their software to co-exist, its a good idea to branch. Else, it is'nt. The cost involved in merging, re-testing and fixing issues is the price one pays for maintaining multiple versions. A good idea would be to phase out each release and lock branches once they reach certain feature quality standards. Ofcourse, regular merges from the mainline will alleviate the burden of re-testing and re-evaluation.