Version Control Workflows

Tags: Git, Mercurial Workflow

Version Control Workflows

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.

[!/28651!]

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.

[!28652.png!]

codeBeamer makes it very easy to implement in the Integration Manager Workflow, please read Integration Manager Workflows & Pull Requests with Git and Mercurial for details.

Dictator and Lieutenants Workflow

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.

[!/28653!]

Again, Git is entirely flexible about this, so you can mix and match and choose the work-flow that is right for you.

The pictures on this page are from Why Git is Better Than X with their permissions.