Git is popularly known as a Version Control System (VCS), but it's more than that. Git is a Software Configuration Management (SCM) system, because besides file version control, it also has software development process features such as integration team facilities, merging changes on files, tagging, branching, and more.
Linus Torvalds started Git development in 2005 with some goals in mind: speed, simple design, strong support for non-linear development, fully distribution and ability to handle large projects (Chacon 5). 75 days after the beginning of its development, Git managed the release of the Linux Kernel 2.6.12 ("Git Software").
Unlike many VCSs (such as SVN) that are Centralized Version Control Systems (CVCS), Git is a Distributed Version Control System (DVCS). This is a crucial difference that sets Git apart from most VCSs (that are CVCSs).
Git's model implies that there's no central repository, so each client is a repository, and not only has a copy of the versioned files. Typically, each client has its own local repository, and in fact all the work can be done by this way (in a single person project). But this is not recommended because any local hard disk issue might become a huge problem. You should have at least one more repository, in another machine, typically a remote repository on a web server. For teamwork, that remote repository becomes a shared repository, acting as a facilitator for all team members. What one needs to do to keep everyone up to date is simply send (push) their changes to and get (pull) others changes from that repository. Thus the shared repository behaves similarly to a central repository, but this is very different from the centralized model, including the possibility of multiple shared repositories to coexist.
Because each client has a full local repository, nearly every operation is done locally, which means plenty of speed and easiness. On the other hand, in a centralized model each client has only a copy of the files, so each commit, and many other operations, like consulting the change history, needs to connect to the central repository, often on a remote server, which results in connection, latency and speed issues.
To really understand how Git works and use it effectively, it's essential to understand its basic concepts about storage and file versioning.
The way some other VCSs (e.g. SVN) handle files and versions is storing the base files and then saving the changes that were made (Chacon 6). So you have the original file and subsequent deltas for each change. Git works differently, for each file change (commit) Git stores a snapshot of all files, but it has intelligence to not duplicate unmodified files. (Chacon 6). So Git works much more like a mini filesystem.
That is the key about how Git works, and it's what makes it better and richer than other VCSs.
Now, head to Git Workflow to learn about the three file states on Git (modified, staged and committed), and their three corresponding Git sections (working directory, staging area and Git directory).
Chacon, Scott. Pro Git. Apress, 2009.
"Git Software" Wikipedia , n.d. Web. 19 January 2011 <http://en.wikipedia.org/wiki/Git_(software)>
Introduction to Git by Flavio Silva is licensed under a Creative Commons Attribution 4.0 International License.