Let's look a little deeper at the architecture underlying Git. First of all, a repository is really just a database. This database contains every bit of information required to store a project, manages revisions, and show its history. It contains not just the complete working copy of the files, that are the project's contents, it actually has a copy of the repository itself. All this information, by the way, is stored in the .git subdirectory tree. Each repository also has configuration parameters, including the author's name, and email, address, a list of all the branches, both locally and remote. When you clone a git repository, you make a copy of it that you want to use yourself. This configuration information is not carried forward. That information is based on your site, because it contains information such as your name and email address. The two important data structures in the repository are the object store, that contains the full contents of the project, and the index, which changes dynamically as the project changes. It has a picture of the overall project structure at any given time. There are four kinds of objects stored in what's called the objects store, and together, they contain everything you know about a project. You have a Blobs. Those are Binary Large Objects. That's where most of the bytes are. These are versions of files content that doesn't actually contain the file's name or any other metadata, just the content that's in files. Trees - these record a blob identifiers, path names, metadata, etc. They are referred to sub-directories and objects within them. Commits - every time a change is made to a repository, a separate objects is made for the commit. That contains all the metadata describing the change. And then tags, these are optional, human-friendly names, that you can use in order to retrieve a particular point in the project history or commit, without having to type in those long hexadecimal numbers. Now, most version control systems work with file names. Git really doesn't care about file names. It works with contents, and it also doesn't care about files themselves. If you have two files and two directories with different names, there is only one binary blob stored, for instance. If the file changes, the hexadecimal string associated with it changes, and a new blob is associated with the new content. This makes comparisons extremely fast. Git only compares these hexadecimal identifiers, rather than actually compare the blobs. It's only if the hexadecimal identifiers are different, that the diffs will actually look at the actual file content. So, every time a file changes, you make a new binary blob. You don't have to keep a copy of a file at some other point in time, the way other revision control systems do. This tends to keep the size of the repository smaller. File names are just metadata. They're distinct from the contents. The contents of the .git subdirectory tree don't look at all like the working directories that they represent. You can easily remove all the working files in your project, and then just simply restore them with a "git restore" command just totally from that .git directory. So, that's a little bit of a review of some of the architecture that git employs.
