Git as a content-addressable filesystem is a very powerful tool that you can easily use as more than just a VCS.
In a DVCS, clients don't just check out the latest snapshot of the files: they fully mirror the repository... Every checkout is really a full backup of all the data.
Conceptually, most other systems store information as a list of file-based changes. These systems think of the information they keep as a set of files and the changes made to each file over time... Git doesn't think of or store its data in this way. Instead, Git thinks of its data more like a set of snapshots of a mini filesystem... This makes Git more like a mini filesystem with some incredibly powerful tools built on top of it, rather than simply a VCS.
It is important to note that the
fetchcommand pulls the data to your local repository - it doesn't automatically merge it with any of your work or modify what you're currently working on. You have to merge it manually into your work when you're ready.
git pullgenerally fetches data from the server you originally cloned from and automatically tries to merge it into the code you're currently working on.
The way Git branches is incredibly lightweight, making branching operations nearly instantaneous and switching back and forth between branches generally just as fast. Unlike make other VCSs, Git encourages a workflow that branches and merges often, even multiple times a day.
A branch in Git is simply a lightweight moveable pointer to one of these commits.
To switch to an existing branch, you run the
Git determines the best common ancestor to use for its merge base; this is different than CVS or Subversion (before version 1.5), where the developer doing the merge has to figure out the best merge base for themselves.
In Git it's common to create, work on, merge, and delete branches several times a day.
In Git there are two main ways to integrate changes from one branch into another; the merge and the rebase.
At the core of Git is a simple key-value data store. You can insert any kind of content into it, and it will give you back a key that you can use to retrieve the content again at any time.
If someone at any point in the history of your project added a single huge file, every clone for all time will be forced to download that large file, even if it was removed from the project in the very next commit. Because it's reachable from the history it will always be there.