Git vs. SVN

Git only requires a connection to the central repository (or other repositories) when pulling or pushing. All other operations can be performed locally. SVN requires for nearly every operation (except of a diff) a connection to the SVN server.

(Smart)Git has all repository data available locally. Hence, a log is very fast and does not only show branch forks but also merges. Searching in file contents of old commits is also possible. To show a log, the SVN client needs to connect to the SVN server. A Subversion log usually shows the past linear hierarchy, SmartSVN also has a Revision Graph feature but that requires additional slow commands to show merges. Tags also may clutter the display as branch-like forks because of the nature of SVN tags and branches (copy operations).

A renamed or moved file in Git is committed as new and missing file pair. When showing the log Git will automatically detect whether the file has been renamed or moved. SVN needs explicitly invoked commands to mark renamed or moved files. This is cumbersome and has only advantages if the file content has changed so significantly that an automatic detection isn't possible anymore.

Git has an "index", somethink like a separate area between the repository and the working tree where the next commit can be prepared. SmartGit allows to easily edit this index using a 3-pane-compare (repository vs. index vs. working tree). That way it is quite easy to produce clean commits. With SVN, it is complicated and error-prone to commit different changes inside the same file to different commits (e.g. by undoing parts of the changes in an editor, committing, redoing the changes).

In Git every commit first goes to the local repository. Only when pushing, commits are sent to other Git repositories. The user has explicit control over what is being sent to other repositories, so it is easy to create private, local branches. Private branches are not possible with Subversion. Every commit goes to the central repository.

With (Smart)Git you easily can amend, reorder or squash commits. Or you can tell Git to "forget" about unwanted commits. In Subversion, if a commit is in the repository, you only can fix the commit message. You can't change the files, the file contents or the order of the commits any more.

In Git, tags and branches work on top of commit. Actually both are just named pointers to a commit, so mixed revisions (and their possible problems) do not exist. After committing certain files, the working copy remains in a mixed revision state. When creating a tag or branch, this state is not easy to understand from the log.

Even with local changes one get fetch changes from team-mates by fetching them. SmartGit even allows to automatically stash the local changes when pulling (integrating remote changes into local changes) and apply them later. When having local changes and you invoke an update, you always have the risk of getting hard-to-resolve conflicts.