22 03 2020
GIT: Learn by doing. Intro
This is an introduction to my series of articles regarding Git. The information included is essential for understanding the other chapters. If you are familiar with it, you can skip to the next chapter.
There is no “spoon”
Probably, you have been working with Git for quite a long time; but for now, I want to ask you to forget everything you know about Git (like creating branches, committing to the branch, merging branches, etc.) You should forget about the “origin” and the fact Git has branches.
Do you remember how your Git history looks like? It is, probably, something like this (see below), where you can see branch names and that “origin” word:
Now, imagine the same history, but with the “those” strange numbers below each commit.
There is only a commit
You know that Git has commits, and this is what this chapter is all about. It’s all about a commit. There is only a commit. There is so much more in the commit itself I want to tell you about, what you might not to know.
Let’s have a look at what the commit is. You could compare the commit to a point in time associated with a group of actions happened before. You can imagine that the commit is similar to your daily activities, namely waking up, washing your face, getting dressed, etc.
The number of these “dots” in time is completely up to you, and you decide when one dot contains one action and when it contains multiple actions.
This is also what we do to our source code. Instead of washing our face, we wash out some code from a file, rename the file, change the code…but you already know that.
We create commits every day, but maybe not in the way I described above; we create them without thoughtful thinking, “How many of these actions should I put into one commit and how many of them will I put into another one”.
As soon as you move on with the chapters, you will notice that thinking this way is essential to better understand and work with Git.
This is a time machine
One of the most significant powers a Version Control System (VCS) gives us is the ability to return in time.
Git is not different, and, for that purpose, I will call Git – “a time machine”.
You can go back in time and replay the whole history of your actions, from start to the end.
By returning in time to an individual commit, you can analyze the state of the code at that particular time, you can feel the code, and you can smell it. This is precisely what the command
checkout is doing in Git.
To return to a “dot” number 2 ( Rename file a to b ) we would execute:
git checkout 2
One important thing I want to note. Do you remember I told you to forget about branches in Git? Good, with the command above, we don’t checkout a branch with name
2, we checkout a commit itself. Number
2 in this case is an id of that commit. They also call it “a commit hash.”
What is even more critical to understand is that Git also allows us to create a new “dot” from that point in time, i.e., we can create a new alternate history, like in the movie “Back to the Future Part II“.
Now, imagine we change the file z again and commit it.
git commit -m "Add file z"
(I will keep repeating that we have no branches yet; there is only a new commit.)
Having done that (currently only in your mind 🙂), you might think that all other stuff, which you had in the Git history before, is gone … actually, it is not. All the previous commits are still available; however, they are not easily visible in Git.
Doesn’t it remind you of a picture with Doc Brown from above? 😉 I told you, it’s the time machine.
This all means that commit 3a together with a previous commits 2 and 1 will start forming a fork and the whole Git history will look like a tree.
It’s so bad we can’t do that in real life; look how cool it could be 😀 :
Therefore, if you want to see what would happen if you “get dressed” first and, then, “wash your face”, do it and don’t be afraid, Git remembers it all (even without branches.)
This is precisely the power that Git gives us. We can experiment without worrying about the consequences. We can keep changing history, committing, going back, and committing again.
I will repeat – don’t be afraid to “travel in time” with Git. If you start looking at these dotted lines in your Git clients and see the commits instead of branches you’ve used to, you’ll see the power the time machine Git provides you with.
What is in the hash
Since history might become huge with all the different paths, Git doesn’t use numeric values to give commits the number. Instead, Git uses hashes to identify the commits.
What is very important to remember is that hash is a UNIQUE element of a commit. Whatever you do, you can always rely on its being a unique value.
Therefore, every change to the Git history, will CHANGE the hash of that commit. Even if you redo the same action again, Git will still see it as a new “dot” in time, that means a new commit, and a new hash. Such a situation is also shown in the picture above – “File z” was added again as a new commit “3a”
All this information mentioned above will help you easily go into any commit in your Git history, by running
checkout with commit hash at the end. You will need to remember this, as it is very essential for future articles.
git checkout 69e13aa8
Let’s recap what have we learned so far.
- It’s possible to travel in time, by specifying commit hash to
- There is no need in “branches” to create a “branch” like history
- Commit has a unique hash
- Two commits with the same content will deliver 2 unique and different hashes
In the next chapter, you will learn how to create branches without a name and how to see what is not visible in the Git history. Additionally, it will be a more practical chapter than this one.