Selling Git on the Business End

Josh Symonds, Thursday, August 28, 2008 @ 12:55 am

Today I gave a presentation on why Git makes sense for an agile consultancy like ours. It was more challenging than I initially imagined; there are many, many blog posts out there discussing why Git is technically superior to Subversion. But when I searched for posts discussing the business merits of Git I came up short. Git is faster, branches better, it has a local copy of the repository, it's small and cheap, but these are points that sell an engineer. What sells the administrators, the business analysts, the project managers?

I came up with a few cool scenarios to illustrate why we, as a business, should adopt Git -- essentially, why it makes not only my life easier, but why it will make the decision makers incredibly happy too. Then my colleague Jason Sendelbach and I gave a short talk on not only the why of the Git, but how we can start using it. Here I'll summarize our presentation. If you want to use Git in your company, but you have problems selling it to the administration, feel free to crib liberally. These points worked great for me.

Essentially, Git is excellent for agile development houses because it allows them to be more responsive. Agile is all about short sprints and quick response times; Git facilitates an agile methodology and supports engineers using less time, making better code, and working more closely together. That means less time spent on each individual project, and that means more time to spend on new projects. Using Git, development houses can support clients more easily, collaborate more effectively, and control the quality of their code simply and easily -- and that means money to them, and satisfaction to their clients.

Easy Client Support

When I discussed why Git helps us support clients, I actually directly referenced a call I got last week from a client. I think every developer has been in a situation like this. I'm busy programming in the trunk, making new features, when the client phones us and says, "Uhh... you know, we need a change made, and we need it right away." But I'm in the middle of working on stuff! What am I supposed to do? Either I make a new branch, or I roll back the changes I've made in the trunk, or I keep track of which files I made the changes in and make sure I don't commit them. Or I try to finish up my new features in the trunk quickly and head over to the change request. Headaches!

In this scenario, Git works with me, where Subversion presents a stumbling block. The easiest thing to do in Git is use Git stash. In the command line, I just type:

git stash

And suddenly all my changes are saved and my master branch is clean again. I make the changes, commit them, push them to the server, and then:

git stash apply

The new features are rolled back into the master branch and you can continue developing as if you hadn't just gotten a client call. How cool is that? Your project manager immediately sees that this saves time in every step of the process -- you develop not only new features better and more quickly, but you support the client immediately and responsively.

Of course, you can do this just as well with branching. But seeing this happen in the stash is much more visceral and in my small test runs got a lot more punch than creating a new branch, committing to that, and then working back in the master again.

Faster Development Through Collaboration

Apportioning development work in a project is an unenviable task. A project manager has only a certain amount of resources to allocate in order to achieve an amazing web application; ensuring that designers work together effectively is incredibly important in creating a cohesive, and whole, final product. Git helps developers work together on disparate parts of a project quickly and more easily than they can with Subversion.

For example, only a few days ago I was tasked with integrating a merchant account into a project. (I used ActiveMerchant.) I had all the necessary details for my part of the project except for one: the shopping cart was someone else's task. I knew exactly what model objects I would use and how to calculate the amount that would be charged to the credit card, but without the shopping cart my work on the merchant account shouldn't be committed into the main repository. It's sort of a disassociated, floating piece until the shopping cart itself is created.

This was an example that allows us to really talk about how Git's branching is functionally superior to Subversion's, because the solution is the same in both version control systems: make a new branch and work with the developer in that branch. But Git allows us to do this quickly and easily, whereas Subversion is slow and clunky. Git is merely:

git checkout -b cc_processing
git commit -am "Credit card processing integration"
git push origin cc_processing:refs/head/cc_processing

When the shopping cart developer next pulls from the origin, they get a new remote branch called cc_processing. They change into it with:

git checkout -b origin/cc_processing

And they can merge the changes I've made into their shopping cart. Once the two pieces function as a cohesive whole they are integrated into the trunk of the project. Collaboration is as easy as sharing a quickly created branch; changes are pulled in faster and easier. In short, developers work better as a team with Git.

Code Quality and Requirements Management

Git's main selling point to the higher-ups, though, is that it can allow them more direct control in the development process. Because no repository is a special, central repository, we can easily and quickly set up multiple repositories with different purposes, that give the project managers more immediate control over the quality of the project.

Let's say that we have a project with a bunch of developers and one project manager. There are two repositories in the project. The first is the blessed repository; all the developers have read access to it, and they constantly rebase their local repositories from it. They make their changes locally and then commit to a second, different repository -- the unclean repository.

The project manager checks out the unclean repository and looks at all the changes that have been made in the developer's branches there. They can go over them with a fine toothed comb, compare them to requirements, ensure test coverage, and when they are satisfied, the changes are merged into the master and pushed to the blessed repository.

You should have seen the project managers' eyes light up when I hit this point. It was like I could hear them thinking: "We can vet the code against the requirements before it's pushed? We can do sensible, easy quality control? And it doesn't even mean a lot of work for us?" I have to say it was a pretty neat moment.

How Do We Integrate It?

So now those bigwigs are sold. The project managers want to sign on to the big Git train, and soon the business analysts will be branching and rebasing as if they'd never used Subversion. But you can't just start using Git. In most businesses, no matter how agile they are, there are processes already in place, and in our business at least that process is heavily based around Subversion.

How do we start changing that process to use Git?

This is where Jason Sendelbach came to the rescue and talked about git svn. Since I use Git primarily by itself I had very little experience with git svn, but actually it really gelled into our existing infrastructure: we keep our existing Subversion server and even CruiseControl setup and git svn just builds on top of that, giving us the local power of git but without changing our existing Subversion setups.

Over time, new projects will be set up using only Git: but for now, to get developers using Git locally without committing ourselves to a new process, we're going to be using git svn and sending our developers to the excellent Git - SVN crash course. We'll get the benefits of an agile Git repository and over time we'll migrate to actually use one.

I hope you find these tips as useful as they were for me. And hey, there might still be holdouts among the higher-ups: if you have any additional tips for ways to sell the business end on Git, why not share them with all of us?

Related posts:

1. Selling colleagues on progressive enhancement
2. git how to: ignoring files in git
3. Advice to Developers: Try Understanding the Business
4. Tech Terms that Drive Business People Crazy
5. Thinking about starting a SaaS or eCommerce business?

Comments (3)

Software Development

Comments: 3 so far

• Leave a comment
• Comment feed for this post
• TrackBack URL

1. 

   IMHO, while Git is nice, it misses a nice and full featured GUI like TortoiseSVN. Probably that’s the key for the SVN popularity.

   Comment by Frederico Caldeira Knabben, Thursday, August 28, 2008 @ 4:32 am

2. 

   I would say as long as wikipedia continues to say

   “Git is noticeably slower on Windows especially for commands written in shell scripts[44] primarily due to heavy cost of fork emulation performed by Cygwin”

   business interest will continue to be minimal

   Comment by Ben Fulton, Thursday, August 28, 2008 @ 11:37 am

3. [...] talk business. Josh Symonds on selling Git on the business end: Essentially, Git is excellent for agile development houses because it allows them to be more [...]

   Pingback by Labnotes » Rounded Corners 217 - Reading list, Friday, August 29, 2008 @ 1:09 am

Leave a comment