There are many comparison lists to find on the web, but this is one I've created after I tested GIT. I have a lot of experience with Subversion, but I was wondering what the power/advantages of GIT are.
What is GIT?
GIT is a free distributed revision control, or software source code management project with an emphasis on being fast. GIT was initially created by Linus Torvalds for Linux kernel development.
Every GIT working directory is a full-fledged repository with complete history and full revision tracking capabilities, not dependent on network access or a central server.
Several high-profile software projects now use GIT for revision control, most notably the Linux kernel, Perl, Samba, X.org Server, Qt (toolkit), One Laptop per Child (OLPC) core development, Ruby on Rails web framework, VLC, Merb, Wine, SWI Prolog, DragonFly BSD and the Android mobile platform.
- distributed: you are no longer dependent on 1 server. You can also retrieve data from your "neighbours" which have also checked out some code of a server. The retrieval of this data is called a pull operation; the sending of data to your neighbours (also called remotes), is called a push operation
- .git folder: in contrast of Subversion in which each folder has a .svn directory, GIT will only create 1 .git folder. In this folder, each file/folder which is changed/added/deleted/renamed/ ... gets tracked. This .git folder is basicly an index in which files/folders can be quickly retrieved
- DAG all data gets stored as a DAG (Directed Cyclic Graph). SVN uses a tree architecture. The use of a DAG gives GIT the possibility to create branches from different "trees". Different knots can point to different branches
- GUI tools: if you don't like the commandline to use GIT, you can use of the many GUI tools like TortoiseGIT to keep track of changes in your directory in a graphical way
- Merging: the way GIT thinks about merging is more flexible than SVN. For example: you can merge little parts of files to another branch, and leave the other changes in the file in your working copy. This is called: committing a hunk
- changes: the changes to a tree can easily be e-mailed to other persons
- history: asking for the history of file/folder in GIT is so much faster than SVN as you don't need a central server to ask for history. All history is stored in an index file
- goal: GIT is very useful for open source projects: contributors can simply make patches, branch, merge branches of various contributors, all independent on the master server
- distributed: it seems to be an advantage to move from a centralized to a distributed system, yet, it seems weird that you can retrieve data from the neighbours as well (and not only from a central repository). For me, this is something really strange. Imagine each developer has its own GIT local repository. If you want to update your local repository, you have to fetch the updates from all of the developers? Or do you still need a central repository? But then I need to commit AND and I need to push the changes to the central repository. That's 1 extra operation compared with SVN
- high learning curve: a wide variety of commands can make this tool very complex. If you want to introduce GIT in your team, I really think you should have at least one developer which has advanced knowledge/experience of GIT. Or each of the developers needs to be for 100% committed to use this new version control system. Otherwise, people will be quickly annoyed.