Workflows: centralized versus distributed version control systems
An interesting read: at Why Git is Better Than X (where X is one of hg, bzr, svn and perforce) Scott Chacon maintains a list of reasons why you should switch from your good old version control system to Git, the fast version control system.
While lots of people are talking about "which is the best distributed version control system?", we at Intland find it more interesting to answer the question "how can you improve your business using a distributed version control system?" and "what kind of workflows can you implement on the top of a good DVCS?". That's why we copied the section "Any workflow" here. Please read through Scott's entire site here if interested.
There are multiple key players in the field of DVCS implementations, and we believe that this competition is good for the industry. Having said that, codeBeamer gives you a freedom of the choice: it supports both Git and Mercurial. Give it a try.
Any Workflow
One of the amazing things about Git is that because of its distributed nature and super branching system, you can easily implement pretty much any workflow you can think of relatively easily.
Subversion-Style Workflow
A very common Git workflow, especially from people transitioning from a centralized system, is a centralized workflow. Git will not allow you to push if someone has pushed since the last time you fetched, so a centralized model where all developers push to the same server works just fine.
Integration Manager Workflow
Another common Git workflow is where there is an integration manager—a single person who commits to the 'blessed' repository, and then a number of developers who clone from that repository, push to their own independent repositories and ask the integrator to pull in their changes. This is the type of development model you often see with open source or GitHub repositories.
Dictator and Lieutenants Workflow
For more massive projects, you can setup your developers similar to the way the Linux kernel is run, where people are in charge of a
specific subsystem of the project ('lieutenants') and merge in all changes that have to do with that subsystem. Then another integrator
(the 'dictator') can pull changes from only his/her lieutenants and the push to the 'blessed' repository that everyone then clones from
again.
Again, Git is entirely flexible about this, so you can mix and match and choose the workflow that is right for you.
Posted at 02:26PM Apr 20, 2009 by Intland Team in Business | 0 Comments