/ / What Is Git: How Is It Used as a Version Control System?

What Is Git: How Is It Used as a Version Control System?

Git Basics - depicted with wooden cabinet and boxes

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.

Note

Git is not equivalent to GitHub.

Git is a Version Control System, while GitHub is a Version Control Hosting Service for hosting .git repositories.

You can learn more about the differences between the two technologies in our Git vs. GitHub article.

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

Note

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

In other words, whoever a project’s .git repository gets distributed to will get all the files, commits, and branches in that repository.

Note

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.

Note

  • The term “remote” means “elsewhere” — not “online”. Therefore, 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 — automatically named .git — is a hidden folder wherein Git stores all recorded versions of your project’s file(s).

Files states in Git

The three primary states (conditions) a file can be in are: modified, staged, or committed.

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

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.

Committed state

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

In other words, 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 the location Git will place it.

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.

As such, any folder you create 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. You create a working directory while Git creates a .git directory.
  • Find out more about the differences between a working directory and a Git directory in our Git vs. Working Directory article.

Staging area

The staging area is a file Git uses to store details about files it is about to commit into the .git directory.

Note

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

Git directory

The .git directory is the folder Git creates inside the working directory you have instructed it to track.

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 an online platform like GitHub).
  • Files in the committed state reside in the .git directory.
  • A repository is another name for a folder.

The basic Git workflow

Working with the .git Version Control System looks something like this:

Git basic workflow diagram

Step 1

Modify files in the working directory.

Note

Any file you alter becomes a file in the modified state.

Step 2

Selectively stage the files you want to commit to the .git directory.

Note

  • Any file you stage (add) into the staging area becomes a file in the staged state.
  • Staged files are not yet in the .git database.
  • Staging puts information about the staged file in a file (called “index”) located inside the .git repository.

Step 3

Commit the file(s) you have staged into the .git directory.

In other words, permanently store a snapshot of the staged file(s) into the .git database.

Note

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 article for a comprehensive guide on using Git efficiently.

Credit

Featured Image: Brown and blue wooden cabinet by Nana Smirnova

Get Helpful Resources in Your Inbox

A CodeSweetly Digest

Similar Posts