This is taken from an argument I made back in November for why our entire company should adopt git. There may be errors in it, and it’s fairly out of date. Given those caveats, I hope it’s useful.

In short, I choose git and github based on my beliefs about software development at the organizational and individual levels.

As a software craftsman, I believe in sharp tools

Tools amplify your talent. The better your tools, and the better you know how to use them, the more productive you can be. […]

Many new programmers make the mistake of adopting a single power tool, such as a particular integrated development environment (IDE), and never leave its cozy interface. This really is a mistake. We need to be comfortable beyond the limits imposed by an IDE. The only way to do this is to keep the basic tool set sharp and ready to use. – The Pragmatic Programmer, Chapter 3

While Mercurial provides a command-line tool, it’s interface is limited. Git provides a more rich set of tools for me to poke through my versioned set of source code. Doing so gives me powerful ways to solve unanticipated problems that will be of great importance at some point in the future. Choosing git now lets us prepare for those moments when performance of a difficult operation will be required.

We need to let our craftsmen work with sharp tools, rather than protect them from themselves. – Bruce Tate, author and programmer

I believe in people over process

“Individuals and interactions over processes and tools” – The Agile Manifesto

Given a choice of two tools, one of which favors interactions and empowers individuals more than the other, I will choose the one that empowers nearly every time since I believe that trusting my peers and coaching each other in the use of a powerful concept or tool will lead to a better result overall.

“There is nothing that motivates, or inspires, people like having trust extended to them. When it is, people don’t need to be managed or supervised; they manage themselves.” – Stephen R. M. Covey, The SPEED of Trust, p. 227

Git makes it fast to switch between local forks of code. Doing so it shortens the process of forking, empowering people by reducing the process around keeping track of all of the forks they use. It makes the personal pain less, so that they fork more often and when needed instead of when the benefit outweighs the noticeable cost.

I believe in optimizing the common cases of individual use

Git makes it very fast to switch between local forks of code. It is very fast to clone a remote repo over the git protocol. It is harder to setup a central server using the git protocol. The common cases are clones and switches. The less common case is setting up server infrastructure for use among teams of individuals. GitHub innovates around this space.

I believe in making broad work across an organization globally visible

Discovery and discoverability are the hallmarks of communication, serendipitous invention, and spontaneous collaboration. They are the heart of tools in the agile movement such as Continuous Integration, Big Visible Charts, and Collective Code Ownership. These principles are built on the idea that we must trust everyone involved in building our software to both see the code, see the progress we’re making in building our software, and make changes to any code that they need to to push the software forward. I believe extending that trust is absolutely required if we are to develop software at industry speed.

If we are to develop software at that speed, we need a way for people not only to extend that trust, but to do so in ways that are discoverable by others in the sea of changes that occur when a large organization undertakes writing software. Collaborative community-based tools, like GitHub, built on solid distributed software tools are required to make the host of conceptual development streams visible and discoverable to individual front-line developers.

By using innovations such as following fellow developers, following specific forks, and reading peer comments about specific commits we empower developers to discover community knowledge around our massively changing source base in powerful ways that they cannot simply by interacting with the source control tool.

By choosing a community tool built on an infrastructure and core tool community that prods individual developers to craft the ways they publish their changes to others, we then get individual developers communicating meaningful semantic changes to their peers in ways discoverable chunks sized to the optimal granularity of the discovery scope and mechanism.

I believe in Programming on Purpose, and Not By Coincidence

Part of that belief is that developers should make informed, conscious choices about their actions at every step of the way. They should choose indexes wisely in their database, choose their abstractions correctly given the realities of their software and its environment, and craft their source code history consciously to give those that follow a clear picture of the conceptual evolution of their code.

I believe that using a tool born out of a culture that believes in communicating intent over preserving immutability will shape a developer’s thinking more correctly for harnessing that powerful communication possibility than using a tool from a community that is generally opposed to it. Freezing the code in its coincidental flow of changes by making history immutable disallows a logical communication of changes in favor of a physical communication. A culture that promotes historical immutability will always promote to the developer that the preservation of coincidental timelines above conceptual change communication.

This is a powerful, principled, and irreconcilable difference in the philosophical underpinnings among the tool communities. The blogs and manuals of Mercurial heavily favor immutability over communicating intent.

As a minimalist and computer science advocate, I believe in very clean data structures

“The programmer at wit’s end for lack of space can often do best by disentangling himself from his code, rearing back, and contemplating his data. Representation is the essence of programming” – Fred Brooks, The Mythical Man-Month

In Chapter 3 of the classic book Programming Pearls, Jon Bentley covers data structures and illustrates both in striking detail and in beautiful simplicity how the underlying data structures impact the performance of a program. I would add that it is also clear how that structure alters the possibilities of new code that can use that data and the minds of the programmers approaching it.

Git’s simplistic data structure allowed its initial approach to version a source tree to grow in unexpected ways:

Overall, we will be more likely to see innovative features out of a community around a product with a clean data structure than with communities around tools with less powerful data structures. These innovations may seem small at a cursory glance (like taking advantage of OS filesystem caching on fork switches); in the end they will empower our developers in deeper ways than can be seen at first (making new ways of working cheap).

I believe that community matters when adopting tools – especially open source

Community affects how well you can get your job done because community directly influences:

When the Tool is Truly Revolutionary

When the Community Includes Thought Leaders

Community Includes The Masses