Series Two: Git Essential Training: The Basics

This is a continuation of my previous blog post on Git Essentials: The Basics.

I will be sharing my learning note for the following overview

Overview

The different stages of making changes to your repository

Writing commit messages (how to write good commit messages/best practices)

Write a short single line summary of what the changes (less than 50 character)
Keep each line to less than 72 characters, the reason why is that users maybe viewing it on their computer or mobile device through Github
Write your commit messages in present tense, and not past tense
“Fix for a bug” or “fixes a bug”, not “fixed a bug”
The commit message is a label for changes,
You can develop shorthand for your organization, for example you can begin each commit message with the following for whether you are committing a javascript or css, or is it bug fix
“[css, or js]”
“[bugfix]”
Make sure your commit message is clear and descriptive
Bad: “fix typo”
Good: “add mixing hyphen in project section of HTML”
Bad: “Update login code”
Good: “Change user authentication to use Blowfish”

How to view commit logs that has been made to a project

Type the command git log
The first number is the unique ID, every commit is given an ID so we can identify a particular commit that we might be interested in.
Next is the author who made the commit, it shows the name and email
Date commit was made
Commit message
git help log will show more about the commit command
git log -n 3; will limit the number of commits given to the command which is 3
git log — since=2019–01–0, this command will show all commits since 2019. You can limit commits until
git log –grep=”init”: grep means we are going to globally search for regular expressions, it helps to search for commit messages. It will return any commits that have the string “init” in it.

Key concepts and architecture to enable us understand how Git works

Git three trees architecture

Two trees architecture is what is being used by previous version control system
We have the repository and working directory, we call them trees because they represent a file structure, at the top you have the project directory, and below, you can have more folders with files inside. We use checkout to create a new working directory, and after making changes to our working directory, we commit the changes back to the repository

Git uses a three tree architecture, it still has the repository, and the working directory or copy of the repository, but in between is another tree called staging index. When you make changes in your working directory, you use git add . to add the files before using git commit -m to commit to the main repository. The git add . command enables us to stage the files changed, it is possible to commit without using git add command, but that is the way it is done in two tree architecture.

As we work with git, it is important to keep these three tree architecture in mind.
Working directory which contains changes that may not be tracked by git yet
Staging index, which contains changes we are about to commit
Repository, this is what is being tracked by git.

Git Workflow

git add . : the period (.) adds everything in the current working directory to the staging index.
git add <filename> : adds the specified file or this single file to the staging index
git commit -m “” is then used to push file to the repository

Hash values (SHA-1)

Git generates a checksum for each change set, which is the hash value
A checksum is a number that is generated by taking data and feeding it into a mathematical algorithm, so the checksum converts data into a simple number, and we call that simple number checksum.
Same data put into the same mathematical algorithm, always returns the same result or checksum. This ensures data integrity, and this inbuilt in git
Data integrity is fundamental
Each hash value is unique and directly tied to the changes inside it.
The algorithm that git uses to create checksums is the SHA-1 hash algorithm.
The number generated from the SHA-1 algorithm is a 40 character hexadecimal string (meaning it contains the numbers 0–9, and the letters a-f)
git monitors not only our changes but also their history

The HEAD Pointer in Git

The HEAD pointer points to the tip of the current branch in a repository
The HEAD references a point to a specific commit in the repository, as we make new commits, the pointer changes, or moves to point to a new commit.
The HEAD always points to the parent of the next commit
A new branch is a new set of code from what we are working on, and it will be separate from our master branch.
Inside the .git directory, there is a file called HEAD. Inside it, you will find (ls -la .git)

In the next series, I will share my learning note for the following topics:

More from Gino Osahon