Git in a Nutshell — Part II

Branching and Merging

Photo by Yancy Min on Unsplash

Hola, This is the second article on the series Git in a Nutshell where branching and merging happens. If you haven’t read the first part have a quick look here.

Without pages and pages of descriptions, let’s dive in using simple steps.

Here we go…!!!

Git’s Graph Model

Git uses a directed acyclic graph(DAG) to represent commit history.

DAG contains nodes connected with arrows and has no cycles. Each node represents a “Commit”.The arrows point at a commit’s parent(s).

In the above example graph, commit D has two parents — Commit C and Commit B. Commits and the relationships between them form the project history.

A branch occurs if a commit has more than one child.

The above graph is branched as commit A has two children.

A Merge occurs when a commit has more than one parent.

In the above graph commit D is a merge of branch 1 and branch 2.

When using Git clients, commit graph can be easily visualized. In the command line, we can use the Git log command with the graph option to see the same.

Git IDs

Internally Git uses objects to store four things.

1. Commit object — A small text file
2. Annotated tag — Reference to a specific commit
3. Tree — Directories and file names in the project
4. Blob — The content of a file in the project

Git ID / Object Id / SHA-1/hash/checksum is the name of a Git object. This is represented by 40 character hexadecimal string.

Since 40 character Git ID names are not very user-friendly, Git sometimes short ten them to the first seven characters.

Git log command with oneline option can be used to view the shortened Git IDs while Git log command alone will provide you the lengthier version.

git log --oneline

Git Reference

Reference is a user-friendly name that points either to

• SHA-1 value
• Another Reference — Symbolic Reference

Commits can be associated with references.

Master is the default name of the main branch in the repository. An Independent path for a set of commits is known as a branch. If we don’t specifically create a branch in the repository, all the commits belong to the master branch by default.

Branch label points to the most recent commit in the branch which is called the Tip of the branch. Branch labels are implemented as references.

In the above example, master branch has three commits on it with the master branch label pointing to the tip of the branch. Branches are very simple to implement and use very few resources.

Head is the reference to the current commit. It usually points to the branch label of the current branch.

Tag is a reference /label attached to a specific commit that is used to mark important commits.

Branching

First, let’s see the benefits of the branches.

• Fast and easy to create and handle
• Enable experimenting
• Enable concurrent team development
• Support multiple project versions

All commits belong to a branch. By default that is the master branch.

Branch is a set of commits starting with the most recent commit in the branch which traces back to the first commit of the project.

Here starting from the most recent commit on the branch master branch consist of commits A and B while branch1 consists of commits A, B, and C.

Branches can be categorized under two.

1. Topic branch
2. Long-lived

Topic branches are short-lived, usually, for a feature, bug fix, hotfix, or configuration change is done here. Long-lived branches are the master branch, develop, release branches etc.

• Viewing branches

git branch

This will load the list of branches with the current branch with (*).

• Creating branch

git branch <name>

Although we create the new branch, our current branch is still the master branch as HEAD reference to it.

• Checkout

git checkout <branch or commit >

First, it updates the HEAD reference and then updates the working tree with the commit’s files.

To combine the above two processes,

git checkout -b < branch >

Now the next commits are going for branch1, where the master branch is not aware of.

• Deleting a branch

git branch -d <branch>

Deleting a branch is just you delete the branch label. Deleting a branch label will not delete any commits( at least not right away). Branch labels are usually deleted after a branch is merged. If not you may result in dangling commits. If you accidentally deleted the branch label you can use the git reflog command to undo it.

Hope you got the basic idea of branching, will merge the branches we made in the next article :)

Cheers..!!