There are many reasons to create branches in the Update/Commit model and Distributed Version Control really excels in an environment with many branches. Take the examples in the previous post:
In Distributed Version Control, each of these would be “repository/working directories” (repository for short). I put these terms together, because in distributed version control, your repository contains both the complete history and metadata and the working directory in which to edit the files. What this means is that you can branch the code without anyone else knowing. It also means, you *have* to branch in order to get a working directory to edit files. This encourages developers to segregate their tasks into branches and then merge each feature back to a central repository when the work is done.
On the server you might have the following repositories:
- Trunk
- Released (which contains v1.0, v1.1, and v2.0 labels)
On your local machine you might have the following repositories based on the Trunk repository on the server:
- Foo Feature
- Bar Feature
Once a feature is complete, you can push the changes to the Trunk repository and then delete your local feature’s repository.
This link has a more detailed explanation on how distributed source control works.