Git version control system

I was given a Bertelsmann Technology Scholarship from Udacity. I am very impressed with its overall course structure and content. There are basically two parts: version control (using Git) and cloud computing (using AWS).

As someone with experience as a SysAdmin, I can appreciate what a godsend the creation of Source Control Managers (SCM)/Version Control System (VCS). Git is the most popular VCS. GitHub being the most popular application of Git. A VCS is an efficient way of managing code changes. Back in the day, anytime changes were made to a script (code), a backup copy was made before the changes. This became a rather tedious and complicated process to manage.

At a high level, Git can be broken into three parts, work area, stage area, and storage area.

The way it works is pretty simple: The work area is where you make changes to the project. The changed files are added to the staging area and when ready, these files are pushed as a snapshot of the project to the storage area

To understand the “big picture” you have to know the basic terminology and how the various parts fit together and the system work. Git can be thought of as a series of snapshots of the project at a moment in time.

Working Area: is the project directory where modification happens.

Staging Area/Staging Index/Index: is a file that keeps track of what goes into the next commit.

Repository/repo: is a directory than holds the commits.

Commit: the basic unit of Git. It stores a reference to a snapshot of the project at the moment commit was made.

SHA is basically an ID number for each commit.

Checkout when the content in the repository has been copied to the Working Directory/Area.

So the workflow for version control with Git is:

  1. You modify files in your working directory.
  2. You add only the specific modified files from step 1 to the staging area.
  3. You do a commit, which takes the files as they are in the staging area and stores that snapshot permanently to your Git directory.