# Would I choose Git again?

DevFeed: [Would I choose Git again?](<https://devfeed.tech/articles/would-i-choose-git-again-33355.md>)

Original publisher: [Read original article](<https://timkellogg.me/blog/2011/01/02/would-i-choose-git-again>)

Published: 2011-01-02T00: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>), [ASP.NET](<https://devfeed.tech/topics/aspnet.md>), [web applications](<https://devfeed.tech/topics/web-applications.md>), [Development](<https://devfeed.tech/topics/development.md>)

Tags: [asp-net](<https://devfeed.tech/tags/asp-net.md>), [git](<https://devfeed.tech/tags/git.md>), [merge](<https://devfeed.tech/tags/merge.md>), [refactoring](<https://devfeed.tech/tags/refactoring.md>), [repository](<https://devfeed.tech/tags/repository.md>)

## AI overview

The author reflects on using Git in an ASP.NET team after previously comparing it with Subversion. They value Git's lightweight branches, merging options, rebasing, cherry-picking, and its support for moving hotfixes between production and development branches. The article also notes that the team initially reacted negatively to Git.

## Source excerpt

I wrote a post a few months ago about the reasons we chose to use Git over subversion and I think it's time to follow up that post and write about how its gone so far. We're an ASP.NET outfit, and as such there are a few considerations that might not apply to, say, the Linux kernel team. I'm going to break this up into three parts: my perspective, my team's perspective, and some tips for anyone who might want to also try using Git.My Experiences With GitI seriously love using Git. I make a branch for everything I do just like they recommend. An old-school member of our team made a comment, "we always considered branches as something to be avoided", hinting at SVN branches' trait of being hard to manage and keep in sync with the trunk. Git branches are very different from SVN branches - they are very light and easy to keep up to date.Git has some seriously awesome merging mechanisms. First, you can select from a list of merge algorithms (you really only need one of these, but hey, its great to have choices just in case). Then they also have rebase and cherry-picking. These last two aren't regular merges because their algorithms look at the history of the entire repository and make several [and possibly hundreds of] incremental merges. Because these schemes take history into account, you can actually do some serious refactoring and still apply patches to both the production and development branches with relatively little effort.Our team develops and maintains a web application that our company sells as a service. As such, we don't spend time on installers or maintaining previous versions because the only versions that matter are the version that's in production and the development version. Git allows us to cherry-pick hotfixes from development into production (or vice versa) without really thinking much. This would have been a small nightmare in SVN (and invoke suicidal tendencies in TFS). Back when we were using TFS there really wasn't any process or procedure that w