Git is a Distributed Version Control System (DVCS) used to save different versions of a file (or set of files) so that any version is retrievable at will.
Git also makes it easy to record and compare different file versions. This means that details about what changed, who changed what, or who initiated an issue are reviewable anytime.
It is important to note that Git is not equivalent to GitHub.
Git is a Version Control System, while GitHub is a collaborative platform for hosting
What is a Version Control System?
A Version Control System (VCS) refers to the method used to save a file’s versions for future reference.
Intuitively, many people already version control their projects by renaming different versions of the same file in various ways like
blogScript_definite_final.js, and so on. But this approach is error-prone and ineffective for team projects.
Moreover, tracking what changed, who changed it, and why it was changed is a tedious endeavor with this traditional approach. Thus, the importance of a reliable and collaborative version control system like Git.
What Git is Not
Git is not a Local Version Control System (LVCS) that saves file changes in a unique format on a local hard disk — without any collaborative support.
It is also not a Central Version Control System (CVCS) that, although supports collaboration, stores all the versioned files centrally on a single server.
What Git Is
Git is a Distributed Version Control System (DVCS) that allows clients to clone an entire project’s repository onto their disk.
In other words, Git enables the storage and simultaneous manipulation of a file’s versions on multiple servers (computers). Thus, if a server dies, the project’s repository is still retrievable from another server that has a copy.
Additionally, many DVCS — including Git — have remote repositories (i.e., an online folder) that foster collaborative work on projects with anyone, anywhere, at any time.
The term “distributed” means a project’s entire repository gets distributed whenever the repository is shared. Hence, whoever receives a copy of a project’s
.git repository gets all the files, commits, and branches in that repository.
This “distributed” system is in sharp contrast to other version control systems that only share whatever single version a user has explicitly checked out from the central/local database.
What is a Remote Repository?
A remote repository refers to a duplicated copy of a project’s
.git repository hosted elsewhere — be it on the internet, a network somewhere else, or on a different location on your computer.
Therefore, remote repositories are like any local directory — in that, they are just folders.
However, the difference is that only the person with the system can access a local repository. In contrast, remote repositories — located on an open platform like the internet — are accessible by anyone, at any place, at any time.
Thus, remote repositories facilitate dynamic collaboration on projects.
- A term “remote” means “elsewhere” — not “online”. Hence, a
.gitdirectory duplicated to a location “elsewhere” on your local system is still a remote repository.
Moreover, regardless of the type of remote repository, all the standard
fetchoperations are still applicable.
- The Git local repository — which is automatically named
.git— is a hidden folder wherein Git stores all recorded versions of a project’s file(s).
Files states in Git
In Git, there are three primary states (conditions) a file can be: modified state, staged state, or committed state.
A file in the modified state is a revised — but uncommitted (unrecorded) — file.
In other words, files in the modified state are files you have modified but have not explicitly instructed Git to monitor.
A file in the staged state is a modified file, selected — in its current state (version) — in preparation to be saved (committed) into the
.git repository, during the next commit snapshot.
Once a file gets staged, it implies that you have explicitly authorized Git to monitor that file’s version.
Files in the committed state are files successfully stored into the
Thus, a committed file is a file in which you have recorded its staged version into the Git directory (folder).
The state of a file determines its location.
There are three key places versions of a file may reside while version controlling with Git: the working directory, the staging area, or the
The working directory is a local folder for a project’s files. This means that any folder created anywhere on a system is a working directory.
- Files in the modified state reside in the working directory.
- The working directory is different from the
.gitdirectory. That is, you create a working directory while Git creates a
- Check out this comparison post for more differences between the two repositories.
The staging area — technically called “index” — is a file, usually located in the
.git directory, that stores information about files next-in-line to be committed into the
Files in the staged state reside in the staging area.
.git directory is the folder (a.k.a. repository) that Git creates inside the working directory you have instructed it to track.
.git folder is where Git stores the object databases and metadata of the file(s) you have instructed it to monitor.
.gitdirectory is the life of Git — it is the item copied when you clone a repository from another computer (or from an online platform like GitHub).
- Files in the committed state reside in the
The basic Git workflow
Working with the Git Version Control System looks something like this:
- Modify files in the working directory.
Note that any file you alter becomes a file in the modified state.
- Selectively stage the files you want to commit to the
Note that any file you stage (add) into the staging area becomes a file in the staged state.
Also, be aware that staged files are not yet in the
Staging means information about the staged file gets included in a file (called “index”) in the
- Commit the file(s) you have staged into the
.gitdirectory. That is, permanently store a snapshot of the staged file(s) into the
Note that any file version you commit to the
.gitdirectory becomes a file in the committed state.
Git is a brilliant version control system for competent versioning, management, and distribution of files. Check out this simple guide to learn how to use Git efficiently.
Featured Image: Brown and blue wooden cabinet by Nana Smirnova