# Why we chose Git instead of Subversion

DevFeed: [Why we chose Git instead of Subversion](<https://devfeed.tech/articles/why-we-chose-git-instead-of-subversion-33352.md>)

Original publisher: [Read original article](<https://timkellogg.me/blog/2010/10/12/why-we-chose-git-instead-of-subversion>)

Published: 2010-10-12T00:00:00Z

Content type: opinion

Language: en

Sources: [Tim Kellogg](<https://devfeed.tech/sources/tim-kellogg.md>)

Topics: [Git](<https://devfeed.tech/topics/git.md>), [Development](<https://devfeed.tech/topics/development.md>), [ASP.NET](<https://devfeed.tech/topics/aspnet.md>), [issue tracker](<https://devfeed.tech/topics/issue-tracker.md>)

Tags: [asp-net](<https://devfeed.tech/tags/asp-net.md>), [bug](<https://devfeed.tech/tags/bug.md>), [commit](<https://devfeed.tech/tags/commit.md>), [developer](<https://devfeed.tech/tags/developer.md>), [development](<https://devfeed.tech/tags/development.md>), [distributed](<https://devfeed.tech/tags/distributed.md>), [git](<https://devfeed.tech/tags/git.md>), [repository](<https://devfeed.tech/tags/repository.md>), [scm](<https://devfeed.tech/tags/scm.md>), [tracking](<https://devfeed.tech/tags/tracking.md>)

## AI overview

The author explains why a small software team chose Git instead of Team Foundation Server for source control, alongside Redmine for ALM and bug tracking. The article highlights Git's distributed repository model, personal commits and branches, easy branching, and stash operation as ways to experiment safely and manage changes.

## Source excerpt

I just got a new job as an ASP.NET developer at a small company that is freshly developing itself into somewhat of a software company. The development team is undergoing a ton of changes over the past 6 months (6 months ago there were two developers, now there is five as well as a new director of technology). As part of our changes we took some time to evaluate the tools we use. We had been using Microsoft's Team Foundation Server for source control and a home-grown system for bug tracking but after our evaluations we settled on Redmine and Git.The fact that we are using Redmine for ALM and bug tracking isn't particularly surprising to me because it's a feature heavy and mature product that is very natural to use. There are several other feature heavy mature ALM tools that would fit us, but none that are free (I don't consider Trac feature heavy). Git, however, is a bit of a pleasant surprise for me.For the uninitiated ones, Git is a distributed SCM (source control management) tool. The distributed part means that it works kind of like Subversion except that everyone has a full clone of the repository. When you want to check your code in you commit first to yourself and then push your changes to the rest of the team. More realistically you would be committing to yourself several times and occasionally pushing your changes to the rest of the team when you verify that your code is stable.The benefit of this is that you can maintain your own personal branches of the code where you experiment on certain features without having to push them out to everyone else. I see this as psychologically breaking down the barrier to committing code. I often find that I don't commit code for a while because, even though it builds, I'm not sure if some of the pages will run without errors. However, committing to myself means that I can commit whenever I want and not slow any of my teammates down with potential errors.Git also provides very easy and simple branching. They made it extrem