Workflows: Centralized versus Distributed Approaches
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 implementation?.
Scott Chacon of Why Git is Better Than X wrote an interesting overview about the workflow approaches people tend to use in real life projects. We copied this here. (Note: Scott writes specifically about Git, but this can be generalized to any Distributed Version Control System.
The video below is another interesting presentation about Git (from Linus Torvalds, the father of Git):
codeBeamer Supports Any Workflow!
One of the amazing things about Distributed VCSs (Git and Mercurial) is that because of their distributed nature and super branching system, you can implement pretty much any workflow you want relatively easily.
Centralized Workflow
A very common workflow (Subversion, CVS and CM Synergy support only this workflow), especially for people transitioning from a centralized system, is a centralized workflow. A distributed VCS 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.
Distributed Workflows
Integration Manager Workflow
Another common workflow is where there is an integration manager: that is, a single person who commits to the 'blessed' repository. There are 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.
For more massive projects, you can set up your developers similarly to the way the Linux kernel is run: certain people are in charge of a
specific subsystem of the project (lieutenants) and they 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 then 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 work-flow that is right for you.
This website stores cookies on your computer. These cookies are used to improve your browsing experience, constantly optimize the functionality and content of our website, and help us understand your interests and provide more personalized services to you, both on this website and through other media. With your permission, we and our partners may use precise geolocation data and identification through device scanning. You may click accept to consent to our and our partners’ processing as described above. Please be aware that some processing of your personal data may not require your consent, but you have a right to object to such processing. By using our website, you acknowledge this notice of our cookie practices. By accepting and continuing to browse this site, you agree to this use. Your preferences will apply to this website only.
Note that user-behavior analytics are being captured on this server to improve the Codebeamer user experience.