Elevator pitch for Git a/o DVCS

Question

Imagine you have a friend on the phone (not VoIP) who asks: "What's so special about Git? I'm fine using Subversion." What would be your "elevator pitch" in order to describe the advantage of using a DVCS like Git?

Answer 1

Two words: Merging, branching.

Merging and branching are more easy in Git than anywhere else. Git needed to solve one problem: Merging code written by thousands of developers who are rarely at the same revision. Now try this in SVN:

1. Commit your working copy (without breaking the build for anyone else)
2. Fetch the latest version (without corrupting your working copy)
3. Merge the code with an arbitrary target version while being able to roll back to either your working copy or the target version without the risk of losing any of the three (working copy, target version, merge between the two).

It can be done with SVN but in Git, this is the default mode of operation and therefore, most simple.

Answer 2

Ask him to work/checkout/commit/check logs/revert without access to his network repository (eg. on a plane).

Answer 3

There was already a question similar to this. Also, Eric Sink had a number of articles about DVCS. Both the answers to the other question and the articles may help to build an informed decision. Simply saying that one is better over the other is probably not going to help (Sadly, that seems to be all that Linus does in that respect, which doesn't really help to convince people—at least not me :)).

Answer 4

It's a problem of blub.

Anything you can do in your centralized system, I can do in my distributed system, but my day-to-day DVCS tasks that make me such an awesomely efficient developer can't be performed in your centralized system -- and you can't understand that because you perceive the world with the limitations that your system has placed upon you.

Answer 5

For me, one of the main things you can do in a DVCS like git that doesn't work well in SVN is the following:

1) Create several development branches off of trunk for various features that are under development.

2) Merge code from one feature branch into another feature branch before either feature branch is finished and ready to be merged into trunk.

3) Later, merge the feature branches into trunk.

It's nice to break new features off into separate branches so that trunk stays clean until the features are finished. But, inevitably you run into a situation where a team working on one feature branch has written some code that is needed by a team on another feature branch. If you merge this code across feature branches with SVN, you'll have trouble merging into trunk later on. Git avoids this problem.

Here's another benefit... Your company decides to outsource development of a feature to an Indian contracting company. Or, your Professional Services group needs to add a feature for a customer, and that feature may be productized in the future. You really don't want to give write access to your SVN to the Indian contractor or your PS group. So, they have to build the code outside of source control, and you have to merge it in yourself, detecting and resolving any conflicts yourself without any help from SVN, and losing all of the contractors' check-in history in the process.

But with git, you just give the contractor or your PS group a copy of the repository, and they can commit to it just like a developer. Later, you can use git's features to merge the changes back into your git repository. Git will find the conflicts, and it will preserve history.

Finally, one of the coolest things about git is that you really don't have to convince your friend that it's better than SVN. Because git integrates so well with SVN, your company/friend can happily use SVN while you happily use a git connected to the SVN.

Answer 6

For a developer, the most important difference between DVCS and SVN is speed.

When a command that takes 30 seconds or 4 minutes in SVN instead takes 1 or 2 seconds in Git or Mercurial or Bazaar, it is a huge difference to a developer. Version control becomes a minor task rather than an interruption to your workflow. You don't need to add caffeine & re-invoke your pavlovian ritual for getting down to work; you keep your focus by not losing it.

Other benefits are important, but they are secondary by comparison:

• simpler, more flexible branching and merging, with fewer, simpler merge conflicts
• freedom brom being limited by network access and server uptime
• repo structure which matches your workflow