git vs. svn

This page is to compare pro's and con's for using git or svn.

• git is much faster than most other versioning systems, including svn
• git can even be used in tandem with svn. Sometimes companies make decisions to use svn as a policy, but the developer can create and branch at their own pace and then version the final work into svn.
• git uses a single .git folder at the root of a project as the repository, and doesn't pollute every folder like svn does with .svn folders. This helps for many things, for example with grep recursive searches.
• git is a distributed revision control system, where each developer only needs access to their local project folder to keep working and committing changes. If they want to “push” their commits to a remote repository, they can do this when they choose, or whenever the connection becomes available.
• git allows the developer to commit as they see fit, as many times as they want, with as many branches as they want. The developer can later “squash” multiple commits, remove development branches etc… and make one nice clean commit that can be pushed to the public repository. Since the commit id's are sha-1 hashes, nobody will ever know the difference on the public server when reviewing the log.
• git allows multiple “remotes” which are connections to other repositories for the same project. This could be a connection to a public repository, and/or other developer's repositories. Changes from any of these remotes can be “pulled” and merged easily, as well as “pushing” local changes to a remote if allowed.
• because git is stored in the .git folder in the local project directory, each developer has an entire copy of the repository. This instantly provides redundancy for failures. If a centralized svn repository suddenly becomes unavailable, all developers will lose work because of the inability to commit.
• git allows commits of portions of changes, instead of just the entire file. This is actually the way git works because it tracks “content changes”, not files. You may want a DEBUG variable set for development that shouldn't be committed. git allows you to “stage” any specific change to a file.
• git allows you to easily go back and change the log message of a previous commit to correct mistakes
• branching and merging are much easier in git. Even with svn 1.5, you wouldn't be able to remove a branch that didn't work out without it lingering in the repository archives.

• backup and transport of a collection of projects becomes more difficult because they are not held in a single resource like they are in an svn repository.
• you can't (currently) check out a subdirectory of a project. svn allows you to easily checkout a subdirectory, work with it, commit changes, etc…
• terminal-challenged folks may have reservations about using git because the official windows version of git is provided as part of the cygwin package. However, tk based gui's are available for commit management and staging and do run from the cygwin terminal.
• since commits go to your local .git repository, you need to handle backups of your project. A post-commit hook could be added to help with this for git but remember that git is project based, so you need to do it on each project.

• every conceivable program for development currently supports svn
• tortoisesvn on windows is awesome (tortoisegit is available, but not as refined just yet)
• you can version an empty directory (with git, you need to do something like add a .gitignore file to the folder). In case you are wondering why anyone would want to version an empty folder, it could be for something like a log folder or conf folder where files shouldn't be versioned.
• since the repository can be controlled by an admin, you can ensure that every developer's commits always exist. With git you have the option to actually “reset” the repository to a previous state. In svn, you need to merge an older revision and commit it in order to “go back in time”.
• since you have a central repository, each commit is automatically giving you a “backup” of your work

• it is common for the sake of administration to keep few repositories. This causes totally unrelated projects to be stored in that repository, such as the development of web sites for clients. Once development of a site is finished, it may never be needed again, but it will always remain and take up space in the svn repository. In contrast, since it is advised for git to be used on a project by project basis, all you need to do in git is delete the project directory.