GIT: a useful look at Git Version Control System

Git Basics - depicted with wooden cabinet and boxes

On this Page

Page Sections

Page Sections

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 .git repositories.

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.js, blogScript_v2.js, blogScript_v3.js, blogScript_final.js, 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.

Note:

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.

Note:

  • A term “remote” means “elsewhere” — not “online”. Hence, a .git directory 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 push, pull, fetch operations 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.

Modified 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.

Staged state

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.

Committed state

Files in the committed state are files successfully stored into the .git repository.

Thus, a committed file is a file in which you have recorded its staged version into the Git directory (folder).

Note:

The state of a file determines its location.

Files 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 .git directory.

Working directory

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.

Note:

  • Files in the modified state reside in the working directory.
  • The working directory is different from the .git directory. That is, you create a working directory while Git creates a .git directory.
  • Check out this comparison post for more differences between the two repositories.

Staging area

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 .git directory.

Note:

Files in the staged state reside in the staging area.

Git directory

The .git directory is the folder (a.k.a. repository) that Git creates inside the working directory you have instructed it to track.

Also, the .git folder is where Git stores the object databases and metadata of the file(s) you have instructed it to monitor.

Note:

  • The .git directory 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 .git directory.

The basic Git workflow

Working with the Git Version Control System looks something like this:

Git basic workflow diagram
  1. Modify files in the working directory.
    Note that any file you alter becomes a file in the modified state.
  2. Selectively stage the files you want to commit to the .git directory.
    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 .git database.
    Staging means information about the staged file gets included in a file (called “index”) in the .git repository.
  3. Commit the file(s) you have staged into the .git directory. That is, permanently store a snapshot of the staged file(s) into the .git database.
    Note that any file version you commit to the .git directory becomes a file in the committed state.

In summary

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.

Credit

Brown and blue wooden cabinet photo by Nana Smirnova

Last Updated on August 20, 2020 by Oluwatobi Sofela

Share on facebook
Facebook
Share on twitter
Twitter
Share on pinterest
Pinterest
Share on linkedin
LinkedIn
Share on facebook
Facebook
Share on twitter
Twitter
Share on whatsapp
WhatsApp
Share on pinterest
Pinterest
Share on linkedin
LinkedIn