Moving from SVN to Git in 1,000 easy steps

Git is very, VERY commonly used in a "centralised" manner, so don't worry about that. Once you're used to git, the overhead of having to commit and push whenever you would have just commited in svn is minimal. Still, it will always exist - so the question is "what do you get in exchange"? There's two major things:

First, the two step process lets you perform commits CONSTANTLY on your local repo. Coming from svn, it may take a little bit to figure out why this is good, but trust me, it is. In svn you (typically) are careful about checking in half working code into the central repo. And rightly so; people are (often) relying on the trunk code to be working. You don't want to break the build, right? But anyone who has done non-trivial work with svn will, sooner or later, lose some work that wasn't "ready" to check in. In retrospect, it feels kind of weird to have source control that you aren't supposed to use...

Second, everyone knows that git has strong support for branching. But developers used to svn don't always "get" is that git has REALLY strong support for branching. As in, you should be using it. Right now. Constantly. Are you about to start work on a new issue? Branch. Got a new idea on how to solve that problem? Branch. Unsure if you should branch? Branch. Feeling bored? Branch twice. Okay, I'm exaggerating a little, but only a little. You really should be doing everything in branch, because it's very VERY easy to merge, swap branches, pull changes between branches, shelve a branch and start over, stop working on a branch, restart work on a branch, and generally do whatever you want. Again, anyone who has done non-trivial work with svn will have probably learned that branches are a cunning trap for the unwary - you need to unlearn that. :)

I'm sure there are teams out there using git in a "truly" decentralised manner, but in my experience the point of git (and any other dvcs) is actually that it makes a centralised workflow much less painful for the individual devs.

This is like asking "what's the advantage of driving an Audi S5 over a model T, don't they both get you from point A to B?"

Git is a far more advanced tool compared to SVN. It will enable you to do things that SVN is not capable of, and it will save you from trouble that would have resulted in a multi-day firedrill in SVN.

For example, with Git you can maintain local history on your desktop quite easily. Since there won't ever be conflicts, committing is effortless. But now you have the ability to rollback to a previous state quite easily, far beyond the ctrl-z capabilities of your favorite IDE.

Also, in general with Git merging your changes into the central repo ought to be easier than it was previously. If there are conflicts they'll be easier to sort out, for example.

The thing I notice is that you weren't using branches with Subversion.

For about 4 years now, I've been doing branch based iterative development. This is a great way for a team of engineers to work together and have a continuous release process.

Meaning, you deploy trunk and do development on 'iterative branches' (ie: you have branches called iteration-0001, iteration-0002, iteration-0003, etc...). All works happens on the iteration branches which are then tested and merged to trunk on a regular basis as part of the release process. If you have work that spans more than one iteration, you make a branch off the current iteration.

Unfortunately, subversion has a very hard time keeping track of development that way. The reason is that if you (and your co-workers) want to work on another branch off of the iteration branches (so you don't hold up a release), then merging changes from the iteration branches into your branch become a nightmare because merge tracking on your branch has no way to know what is happening on the other branches. If you don't do it right, you can end up with a branch that can never be merged back.

The way merge tracking is handled is a central design failure of Subversion. I made a long blog posting about this a while back: http://lookfirst.com/2011/04/subversion-mistake.html

Git handles all of this beautifully.

So, while today, you might not need the extra functionality of git, it is good to have a tool which can support your needs in the future.

I've come to see the key distinction between git and SVN as:

* Old workflow: "commit code" and "share code with team" are jumbled together.

* New workflow: "commit code" and "share code with team" are separate actions.

This looks so obvious, but coming from years of using SVN, it took me a while to understand the implications. With git I could fix (with commit --amend) those embarrassing "whoops, forgot to add an untracked file" kinds of mistakes. Over time, I found that my local commits became smaller and more frequent because I can reorder and squash them before pushing (or git-svn dcommitting, as most of my clients run SVN).

Consider a larger change where you might implement it one way, decide you were on the wrong track, back off a bit and implement it some other. With SVN these false paths are either in the common repository confusing the history, or I'm in a disconnected state for an uncomfortably long time. With git, all these changes are local commits that are ultimately kept out of the main history because I've reordered the change history into something comprehensible.

It took me a few months to grok git. Reading an article on the filesystem structure of the repository helped me a great deal.

Indeed. SVN is far from the worst source control system out there, and even as we move on to better once, it's pointedly the system that got a lot of coders into using source control.