I have introduced you the powerful DVCS, Git in my previous post. In this post, I give emphasis on the characteristics and advantages of Git.
Other version control systems like Bazaar, Subversion and CVS treats their data as a set of files and the changes made to each file over time.
Git doesn’t think of or store its data this way. Instead, Git thinks of its data more like a set of snapshots of a mini file system. Every time you commit, or save the state of your project in Git, it basically takes a picture of what all your files look like at that moment and stores a reference to that snapshot.
Most operations in Git only need local files and resources to operate — generally no information is needed from another computer on your network. To browse the history of the project, Git doesn’t need to go out to the server to get the history and display it for you — it simply reads it directly from your local database. If you want to see the changes introduced between the current version of a file and the file a month ago, Git can look up the file a month ago and do a local difference calculation, instead of having to either ask a remote server to do it or pull an older version of the file from the remote server to do it locally.
Everything in Git is check-summed before it is stored and is then referred to by that checksum. This means it’s impossible to change the contents of any file or directory without Git knowing about it. The mechanism that Git uses for this check summing is called a SHA-1 hash. A SHA-1 hash looks something like this:
When you do actions in Git, nearly all of them only add data to the Git database. It is very difficult to get the system to do anything that is not undoable or to make it erase data in any way. After you commit a snapshot into Git, it is very difficult to lose.
Another important thing that should be kept in mind is the three states of files in Git. I will come through that in my next post.