I’ve been using version control for a long time. I’ve posted on the SVN mailing list and given talks advocating Git. Nowadays it seems the conversion to Git is widespread. It’s being used in corporate settings, but there’s a caveat – it’s still being treated as a centralized system. While folks have made the leap from traditional systems like SVN, they haven’t made the real leap to distributed version control. This has lead me to realize the subtle genius of github.com – they quietly direct you to use distributed workflows and make it as straightforward as possible.
Git in the corporate context
While some companies use github.com private repositories, many will set up their own servers like gitolite. In either case, every company I’ve done work for that uses Git to version their internal projects treats the repositories in the same fashion as an SVN server, namely they use centralized workflows.
While this allows developers some advantages of git
- Local history browsing / rewriting
- Local merging
- Local branching
It sacrifices many of the benefits thereof. Most notably, it creates clutter in the shared repository in the form of many branches and tags. This is one of the many problems distributed version control was designed to address! What’s more, and what is sort of a problem with corporate development in the first place is the fact that anyone can push code into the shared repository. Many times this is nothing but crap. The sad fact is good developers are hard to find and the reality in open source projects is only the good code survives. Distributed workflows address this problem by running commits through a series of repositories much like a liquor distillation process!
I won’t name names (T >cough< W >cough< C >cough<), but let’s jut say a BIG company I contracted for was using privately hosted github repositories and still embracing these centralized flows. Several companies, and admittedly my own company Moxune uses these centralized-ish flows with a gitolite server. In the case of Moxune there are only a few developers who are all really good so it’s not as bad. But when you scale up to a dozen or more developers, the results can become toxic.
If you aren’t familiar you should take a minute and read up on distributed workflows. Here’s an illustration of one such workflow called the Integration-Manager Workflow.
The main concept here is that every developer gets their own public repository. Typically the only remote repository you’ll ever find yourself attaching to is origin in the corporate context. That’s how you’ll know you’re using only the bare minimum Git has to offer. If you were treating it the way it was intended, you would have remotes out to all the different developers on your team!
Github makes DVCS easy
Now that you have a basic idea what a Distributed Version Control System (DVCS for short) workflow looks like think back to how things work on github.com… Everyone has their own account and for every project you care to work on you get your own centralized repository. You then clone your centralized repository locally to work on it. When you’re ready, you push to your repository, then submit a pull request to the upstream maintainer whose repository you originally cloned. If this person likes your changes he/she merges them into the upstream project, at which point you can pull or rebase back into your repositories.
People are slow to change
It’s amazing how many people are successfully using these distributed workflows via github.com in open source projects, yet hardly any companies have embraced such workflows. When gitosis and gitolite were the only options to host git repositories on a central server, the argument could be made it was a bit onerous to support DVCS workflows. However, with open source software like GitLab and the private repositories through github.com there really is little excuse to avoid DVCS workflows in the corporate context.
During the reign of SVN it was hard if not impossible to get folks to create their own branches, let alone run their own merges… Now Git has made that approachable for the typical braindead developer. Yet we find ourselves at another roadblock. The tools are out there for much more robust workflows yet many companies refuse to embrace them. For years I’ve argued that a sound understanding of version control technologies is tantamount to a sound understanding of programming itself. Many companies seem to disagree and frankly they are the ones shipping crappy code to production, or at the very least blundering their perfect code into production through antiquated processes.
If you enjoyed this post please consider sharing it!