You do the obvious thing: you make a second copy of your document, and begin maintaining the two copies separately. As each department asks you to make small changes, you incorporate them into one copy or the other. But you often find yourself wanting to make the same change to both copies. For example, if you discover a typo in the first copy, it's very likely that the same typo exists in the second copy. The two documents are almost the same, after all; they only differ in small, specific ways. This is the basic concept of a branch-- a line of development that exists independently of another line, yet still shares a common history.
A branch always begins life as a copy of something, and moves on from there, generating its own history. If you don't ever use the branching feature of your source control system, *are you really taking full advantage of your source control system?* I find that *almost every client I visit is barely using branching at all*. Branching is widely misunderstood, and rarely implemented-- even though branching, like versioning, lies at the very heart of source control, and thus software engineering. Perhaps the most accessible way to think of branches is as *parallel universes*. They're places where, for whatever reason, history didn't go quite the same way as it did in your universe. From that point forward, that universe can be slightly different-- or it can be radically and utterly transformed.
Like the Marvel comic book series What If?
Later it was altered to include his exploits as Superboy. It was altered further to include Supergirl, the bottled city of Kandor, and other survivors of Krypton, further watering down the original idea of Superman having been the sole Kryptonian to survive the destruction of his world. There was also an issue of character aging; for instance, Batman, an Earth-born human being without super powers, retained his youth and vitality well into the 1960s despite having been an active hero during World War II, and his sidekick Robin never seemed to age beyond adolescence in over 30 years. [image: Crisis on Infinite Earths #7:] These issues were addressed during the Silver Age by DC creating parallel worlds in a multiverse: Earth-One was the contemporary DC Universe, which had been depicted since the advent of the Silver Age; Earth-Two was the parallel world where the Golden Age events took place, and where the heroes who were active during that period had aged more or less realistically since that time; Earth-Three was an "opposite" world where heroes were villains, and historical events happened the reverse of how they did in real life (such as, for instance, President John Wilkes Booth being assassinated by a rebel named Abraham Lincoln); Earth Prime was ostensibly the "real world," used to explain how real-life DC staffers (such as Julius Schwartz) could occasionally appear in comics stories; and so forth. If something happened outside current continuity (such as the so-called "Imaginary Stories" that were a staple of DC's Silver Age publications), it was explained away as happening on a parallel world, a premise not dissimilar to the company's current "Elseworlds" imprint. Start juggling too many parallel universes at once, and you're bound to drop a few.
In most source control systems, you can create hundreds of branches with no performance issues whatsoever; it's the mental overhead of keeping track of all those branches that you really need to worry about. I find that the analogy of parallel universes helps developers grasp the concept of branching, along with its inevitable pros and cons. But it doesn't get much easier from there. Branching is a complex beast. There are dozens of ways to branch, and nobody can really tell you if you're doing it right or wrong. Here are a few common branching patterns
They either live forever, or they are eventually killed off. - All branches are created with the intention of eventually merging, somewhere. A branch without a merge is pointless. - As we add branches, our development model gets complicated. But that complication is often justified. The more developers you have on a project, the higher the chances are that one of those developers will check something really bad into source control and disrupt everyone else's work. This isn't meant to be a judgment: it's simple statistics. People make mistakes. The more developers you have, the more mistakes you'll have. And the more developers you have, the greater the consequences when everyone's work is simultaneously disrupted by a bad checkin. So what are our options? 1. *Maximum Productivity* Everyone works in the same common area. There are no branches, just a long, unbroken straight line of development. There's nothing to understand, so checkins are brainlessly simple-- but each checkin can break the entire project and bring all progress to a screeching halt. 2. *Minimum Risk* Every single person on the project works in their own private branch.
This minimizes risk; everyone works independently, and nobody can disrupt anyone else's work. But it also adds incredible process overhead. Collaboration becomes incredibly difficult-- every person's work has to be painstakingly merged with everyone else's work to see even the smallest part of the complete system. The answer usually lies somewhere between these two extremes. Like everything else, branching can be abused. Chris Birmele notes that *branching has its own set of anti-patterns* you should watch out for: *Merge Paranoia*Merging is avoided at all cost, due to a fear of the consequences. *Merge Mania*The team spends an inordinate amount of time merging software assets rather than developing them. *Big Bang Merge*Merging has been deferred to the very end of the development effort and an attempt is made to merge all branches simultaneously. *Never Ending Merge*Merge activity never seems to end; there's always more to merge. *Wrong Way Merge*A software asset is merged with a *previous* version. *Branch Mania*Branches are created often and for no apparent reason. *Cascading Branches*Branches are never merged back to the main development line. *Mysterious Branches*Nobody can tell you what the branches are for.
*Temporary Branches*The purpose of a branch keeps changing; it effectively serves as a permanent "temporary" workspace. *Volatile Branches*An unstable branch is shared by other branches or merged into another branch. *Development Freeze*All development activities are stopped during branching, merging and building new baselines *Berlin Wall*Branches are used to divide the development team members, rather than divide the work they are performing. If you've managed to read this far, perhaps you can understand why so many software development teams are completely sold on version control, but hesitant to take on branching and merging. It's a powerful, fundamental source control feature, sure, but it's also complicated. If you're not careful, the wrong branching strategy could do more harm to your project than good. Still, I urge developers to make an effort to understand branching-- *really * understand it-- and explore using branching strategies where appropriate on their projects. Done right, the mental cost of the branching tax pales in comparison to the benefits of concurrent developmentit enables.
*Embrace the idea of parallel universes in your code*, and you may find that you can get more done, with less risk. Just try to avoid a crisis on infinite codebases while you're at it. [advertisement] PhotoDrop.commakes it simple to create and share online photo albums. Upload your full resolution pictures via the web site or with the free Photo DropZone utility, and you're done. No fees. No storage limits. It's the fastest and easiest way to share photos and create albums. * Tue, 02 Oct 2007 23:59:59 -0800* ------------------------------ Source: http://www.codinghorror.com/blog/archives/000968.html -- To unsubscribe from this feed , click here To manage other subscriptions, click here ~ Powered by RssFwd , a service of Blue Sky Factory, Inc -- _Kevin
