Skip to content

Month: April 2020

GIT. Learn by doing: Chapter 3

Merge commits, not branches

In this chapter, we are going to look closer to the merge process. After you’ve learned, that branch is only a label, time to have a look at what merge is.

Let’s start with some theory and slowly move to practice. First, I want to introduce you to the five rules of the merge:

  • The first rule of the merge is:
    The merge is about merging two commits, not branches
  • The second rule of the merge is:
    The merge is about joining two commits, not branches ( this is not a typo, it’s just very essential )
  • The third rule of the merge is:
    It’s not necessary to merge the last two commits ( those without children ), but any commit can be merged with any commit
  • The fourth rule of the merge is:
    Merging two commits produces a new commit, even when you merge the same commits again
  • The fifth rule of the merge is:
    History of both commits should have diverged and they must have a common parent
Read more: GIT. Learn by doing: Chapter 3

GIT: Learn by doing. Chapter 2

What is a “branch” ?

If you have read the previous two chapters, you should already know that commit is the most fundamental part in Git. Diverged history points (alternate future) makes it possible to create branches. In this chapter I’m going to tell you about the “branches” you knew before – what are those, and why do you need them?

It appears that branches which you see in Git client, are only labels by themselves. It’s a human-readable reference to a commit. It’s like a Domain Name System (DNS). Domain name resolves to an IP address, and the branch resolves to a Git commit.

This brings us the first valuable property of a branch. Your commit can have as many labels as you want, and because of that, labels don’t have a time they’ve been created. Remember the task from the previous chapter? Have a look at the picture below. I’ve just added 5 “branches” to the dangling commit I had, while the branch was created at 28 of march, branches/labels are placed now.

Branches are labels
Branches are labels

The second and most valuable point is that removing a branch doesn’t remove the commit itself. It solely removes the label on that commit. I repeat – it SOLELY removes the label on that commit. Very important! Commit stays in history, and even if you do not see it, you can find it as I’ve already described in the previous chapter.

Enough theory it’s time for another exercise.

Read more: GIT: Learn by doing. Chapter 2

GIT: Learn by doing

This is a series of articles about Git (https://git-scm.com) version control system (VCS). I aim to show you Git from a different perspective, starting with the central part of Git – commit and going further into the branches and remotes. You will see what is in reality underneath “origin”, why the button “Create branch” in Jira/GitHub/Gitlab makes no sense, how to merge unmergeable branches, and much much more.

Most of the articles will include tasks to execute in a terminal. I strongly advise you to do them. This way, you will get a better understanding of the explanations. To simplify the bootstrapping of the tasks, I will include a bash/powershell script, which will prepare a basic repository structure.

I hope, as soon as you finish through all the articles, you will level up your Git skills.

Chapters so far:

Read more: GIT: Learn by doing Read more: GIT: Learn by doing