Git is a Distributed Version Control System (DVCS) used to save different versions of a file (or set of files) — wherein any version is retrievable at will.
Git makes it easy to record and compare different file versions. Consequently, details about what changed, who changed what, or who initiated an issue are reviewable anytime.
What is a Version Control System?
A Version Control System (VCS) refers to the specific method employed to save a file’s versions for future references.
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 got changed is a tedious endeavor. 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 stores all its versioned files centrally on a single server.
A Central Version Control System supports collaboration.
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, it enables the storage and simultaneous manipulation of a file’s versions on multiple servers (computers).
As such, 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, anytime.
What does “distributed” mean?
In Git, “distributed” means a project’s entire content gets distributed whenever you share its
In other words, whoever a project’s
.git repository gets distributed to will get all the files, commits, and branches in that repository.
Git’s “distributed” system is in sharp contrast to other version control systems.
Git distributes by sharing everything inside the repository it is tracking.
However, virtually all other VCS only share the specific file 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.
Remote vs. Local Repositories
Remote repositories are like any local directory — in that, they are just folders.
The main difference between the two repositories is that only the person with the system can access a local repository.
However, a remote repository — located on an open platform like the internet — is accessible by anyone, anywhere, anytime.
As such, remote repositories facilitate dynamic collaboration on projects.
- The term “remote” means “elsewhere” — not “online”. Therefore, 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 — automatically named
.git— is a hidden folder wherein Git stores all recorded versions of your project’s file(s).
Files states in Git
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 staged file is a modified file you have selected in its current state (version) in preparation for being saved (committed) into the
.git repository during the following commit snapshot.
Once you stage a file, 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
In other words, 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 the location Git will place it.
The working directory is a local folder for a project’s files.
As such, any folder you create 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. You create a working directory while Git creates a
- Find out more about the differences between a working directory and a Git directory in our Git vs. Working Directory article.
The staging area is a file Git uses to store details about files it is about to commit into the
- Files in the staged state reside in the staging area.
- The staging area is technically called “index” in Git parlance.
- The staging area is usually in the
.git directory is the folder 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 an online platform like GitHub).
- Files in the committed state reside in the
- A repository is another name for a folder.
The basic Git workflow
Working with the
.git Version Control System looks something like this:
Modify files in the working directory.
Any file you alter becomes a file in the modified state.
Selectively stage the files you want to commit to the
- Any file you stage (add) into the staging area becomes a file in the staged state.
- Staged files are not yet in the
- Staging puts information about the staged file in a file (called “index”) located inside the
Commit the file(s) you have staged into the
In other words, permanently store a snapshot of the staged file(s) into the
Any file version you commit to the
.git directory 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 article for a comprehensive guide on using Git efficiently.
Featured Image: Brown and blue wooden cabinet by Nana Smirnova
Get Helpful Resources in Your Inbox
A CodeSweetly Digest