Git, an entire universe to explore

The universe is full of magical things patiently waiting for our wits to grow sharper.

In this article we will explore the Git universe, go through some of it’s magical things & understand it’s language.

What is Git?

The Universe is all of space and time and their contents.

Talking about Git, we can define it by just saying: “It is a version control system” which is too technical, in other words we can say it is all of versions, time and their contents.
Well a version control system (aka: VCS) is a kind of a “database”. It lets you save a version (a snapshot of your complete project) at any time you want. When you later take a look at an older version, your VCS shows you exactly how it differed from the previous one. It is independent of the kind of project / technology / framework you’re working with:

• It works just as well for an HTML website as it does for a design project or an iPhone app
• It lets you work with any tool you like; it doesn’t care what kind of text editor, graphics program, file manager or other tool you use
• It records the changes you make to your project’s files (the contents). This is what version control is about.

What is Git’s purpose?

I’d say universes were made to be discovered yet that wouldn’t be appropriate here, so i prefer to resume the many benefits of using Git for your projects in the following :

• Ensuring a great collaboration between the team members, giving them freedom to change what they need to when they need to in the project without conflicts.
• Allowing to Save a version of the project after making changes simply and properly.
• Ensuring the ability to restore older versions of a file (or even the whole project) effectively.
• Helps you understand how your project evolved between versions. A side-effect of using a distributed VCS like Git is that it can act as a backup.

The rules of Git’s Universe!!

The only way to master git is by understanding how it really works, commands are written everywhere !!

It is a fact that understanding the language a universe speaks is the only way to understand it’s rules and find out it’s secrets. The same goes for git, as it goes for everything else and to understand git’s language we should understand some concepts by answering the following questions :

What’s a working directory ?

It is simply the directory where you plan to work on your project.

What’s a commit ?

A Commit is a snapshot of the project’s currently staged (added to the staging area) changes. You can say it is a safe version of the project.

What’s a staging area?

It is Where commits are prepared, you can say it’s the scene where we gather the project changes to be snapshotted.

What’s a repository ?

The answer would be, the data structure where git stores the changes to your project files, but that would be too technical and too formal, to simplify we’ll say it is: The “container” that stores the snapshots of your project files.

• It stores other things more than just the commits, like the configuration file and a set of references to commits, called heads (we are going to talk about those in another article).
• It is stored in the same directory (working directory) as the project itself, as a hidden sub-directory called “.git”.
• There are 2 types of repositories the local which is the copy saved in your computer and the remote which is saved in a central server or any code hosting services like GitHub.

What do we mean by Hash in git ?

A hash in git is a short digest constructed by an cryptographic algorithm (SHA-1) from a sequence of bytes of any length. In English, it is a mostly unique short code that identify a whole file.

The story of Git’s Universe ?

Understanding the secrets of Git’s Universe would be pretty easy by putting the concepts we just understood together in the following workflow:

A. Initializing your project

To initialize a project you have two possible scenarios which would be :

1. Starting a brand new project using the git init command.
2. Cloning a project from a remote repository using the git clone command.

In both scenarios your Working directory will contain a hidden sub folder named .git which contains all the information needed for git to work.

B. Building a complete feature

Code, code and more code…

C. Staging Your work

To stage your changes is to make them traceable in git, using the git add command. Staging your work is the preparing steps to the feature you are building to be committed.

D. Commit the changes

After staging all the changes, all what left is using the git commit command in order to compresses it and stores it into its own data structure. The compressed object will have a unique name, a hash, and will be stored under the object directory in the .git folder.

In fact when you commit git does only two things in order to create the snapshot of your working directory:

1. If the file didn’t change, git just adds the name of the compressed file (the hash) into the snapshot.
2. If the file has changed, git compresses it, stores the compressed file in the object folder. Finally it adds the name (the hash) of this compressed file into the snapshot.

In short we should understand that a commit is made of 4 things :

1. The name (a hash) of the working directory’s snapshot
2. A comment
3. Commiter information
4. Hash of the parent commit

E. Building another feature and redo the previous…

The data saved with each commit is the way git tracks every file’s status, knows the differences between commits and saves the changes, more precisely git uses the Hash of the commit and it’s parent to do that.

To be continue…

The secrets of a Universe never end…

We just covered the basic workflow that you should understand in order to work with git easily. Yet you should know the proper commands to do so which you can find with details (Mainly in the cheat sheets) in addition to some valuable resources in here.
Other aspects like branching would be detailed in other articles.