Why you should use a distributed version control system
If you’ve ever:
- made a commit and then realized you forgot “one little change”.
- made a commit and regretted it.
- wished you could combine some the past couple days worth of commits into one nice combined commit in the main branch.
- wished you could commit just part of a file.
- needed to drop work on one task and switch tracks to another one without having to make commits with unfinished changes, or commits with changes for one issue and a little of another.
- wanted to make a test spike with version control and without polluting the public repo.
- managed an open source project.
- wanted the security of knowing that there was a valid backup of your revisions on many other peoples boxes, or even just your own.
- been frustrated with branch namespacing issues
- been frustrated with how difficult branching and merging is in most centralized version control systems.
- wished you could just create branches to work on a feature or a bug without worrying about the consequences to the main repo.
- wondered which branch a bug applied to.
- wanted to use version control when you were offline.
- wished you could quickly compare versions of entire trees.
- wished you could easily release everything in the current branch “except that”.
- been concerned about how to scale a system to support hundreds, or thousands, of users.
- been concerned about what would happen if your main repo box died.
…then distributed version control is worth your consideration.