As you may remember, Git is a version control system. But what is behind this definition? How does the system work, and why is it so convenient to use it?
In practical topics, we will show specific examples of how you can version control your projects. But first, let's talk about the basic concepts in general for a better understanding of the processes. The main task when working with git is project versioning. To do this, you need:
work tools that are contained in a .git folder that is created immediately after a new repository is declared;
tracking the state of files in order to understand at what stage of work the project is now and where it will go later;
committing the changes made to the project files when the work is finished.
Thus, three main notions that describe the logic of Git work are .git folder, git commit, and git files stages. Now let's look at these concepts in order, and start with a .git folder.
.git folder
After creating a new repository, you'll have a .git folder. The folder contains everything you need to work with Git. You can also delete it if you don't need Git in your project. The project files will remain on disk.
Here are the contents of a typical .git folder before your first commit:
HEAD is a file containing a pointer either to the current (for the repository) branch or to the current commit;
config – in a Git repository, there is a file named
.git/config, which indeed contains settings specific to that repository. These settings can include the remote repository URL, the user's name and email associated with that repository, and other configuration options.description is used by the Gitweb interface to display a description of the repository;
hooks – this folder contains scripts that can be executed at various stages of Git execution. An example of a hook would be the style check script before pushing to the repository;
info-exclude – files that you do not want to include in the repository are described here.
Git file stages
Here are three main states that your files can be in:
committed, i.e., the file is already saved in your local database;
modified, i.e., there are some unsaved changes in files;
and prepared (staged), i.e., a modified file is marked for inclusion in the next commit.
So, respectively, there are three main concepts about the architecture of Git: the three main sections of a Git project.
The Git directory (.git) is where Git stores the metadata and object base of your project. This is the most important part of Git, which gets copied when you clone a repository from another machine.
The working directory is a snapshot of the project version. The files are unpacked from a compressed database into a Git directory and placed on a disk so that you can use and modify them.
The staging area is a file located in your Git directory that contains information about what changes will go to the next commit. This area is also called the "index", but it is also common to call it the stage area. When you add a file, it first goes exactly to the index, and only after the commit it appears in the repository.
Summing it all up, the basic Git approach looks like this:
You change files in your working directory.
You add files to the index, thereby adding their snapshots to the staging area.
When you commit, the files from the index are used as-is, and this snapshot is saved to your Git directory (.git).
Git Commit
The entire structure of Git is largely based on the need to save the current version of the project. Imagine what it would be like if we didn't have this at all and how inconvenient it would be to work with files. If the file was changed, but there was a need to return to the previous version due to, say, incorrect changes, it would be impossible to restore the status quo and correct the error.
That's why one of the most important concepts in Git is commit, which means saving the state of your project. Every time you make a commit, the system remembers how each file looks at that moment and saves a link to this snapshot. To increase efficiency, if there weren't any changes, Git does not remember these files again but only creates a link to the previous version of the identical file that is already saved.
All changes are stored in a local database, which is created immediately after installing Git on your computer. This means that you will see the history of the project almost instantly. If you need to look at changes made between the current version of a file and a version created a month ago, Git can find the file that is a month old and compute the changes locally.
When searching for Git, it refers to a previously saved string. This means that you can't just take and change the contents of a file without Git knowing about it. This functionality is built into Git at a low level. This way, you won't lose information during the transfer or get a damaged file without Git's knowledge.
Conclusion
The main thing that Git does is archive your working folder and put it in the object's folder with some additional information. If you are familiar with Git, then you have complete control over which files are included in the commit and which are not.