An easy way to understand git and how to be close friends with it

Blog > Version Control | Git

This article is not about how Git is used or how it works. We won’t be discussing Git commands or even branching strategies, no. We will be discussing how to visualize the diffing and committing processes which I believe in turn will make things easier for us. Sadly, a little bit of knowledge on Git is recommended to understand this article. As long as you understand the basics of Git like commits, branches, and repositories you should be fine.

There are hundreds if not thousands of genuinely good articles, guides, and books about Git. Actually, I have a couple of suggestions; Git Pro [] is by far the best source I have come across. It is open-source and totally free. It explains basic stuff and advanced topics very well. To be honest, if you have already read that book, you probably do not need to read this article hence the book is a very good guide to begin and to continue with. Another one is Git's own documentation []. If you do not have a certain amount of knowledge and experience, being official documentation, it might be a little bit overwhelming at first, but after you get the gist of what is going on and what is called what, you will eventually end up visiting these pages often enough. Just remember; Doc's might be a little bit outdated from time to time especially on features added recently. Atlassian and GitHub too, have really good guides that you might wanna check out which might broaden your mind when it comes to certain solutions on managing code bases with multiple/complex branches and repositories.

Well, let's get back to our business then. The thing about Git commands is this; apart from maintenance commands, most of the Git commands are to push commits from one branch to another in a certain fashion and to show them to us to make us understand the differences between branches and commits easier. I realized visualizing these differences and commits in my brain in a certain way really helped me a lot to understand how things work. 

Basically, each commit in Git is a snapshot of the repository in time. Very much like an incremental backup, a commit only contains the difference between the previous one. So without the actual code-base itself, you can build the entire code-base by only using the full commit history of a repository. Starting with the initial commit and adding each commit one by one on top of each other, containing each difference between snapshots, you can build the last version of the code-base from the ground up.

As someone who is obsessed with patterns, thinking commits as a passage of time and small updates to the code-base might help you ease the trouble to understand and help you use Git more efficiently. Think commits as Lego parts. Each part has its own id (hash) and is unique in its own way. When you put these parts together in a certain order you will have the end product. Obviously you can build different Lego cars with the same Lego parts and for a software application treating commits in this fashion may not be logical when it comes to changing commit orders on a real code-base. You will most likely end up with an illogical, unreadable, and bug-ridden code-base that is very likely will never even pass the syntax check. What I am trying to tell is that you visualize commits as Lego parts in your mind. There are obviously times when you can actually change the order of the commits without breaking the code and even functionality but this is not always the case.

The first time I started to use Git in my daily work, it was really troubling, and odd till I started to get the hang of it. But once I understood it, I can not think of myself working without it. Even with small personal projects, at the beginning of every project, the first thing I do is to initialize my local repository whether I use it with a remote repository or not. Some might disagree, but having a repository even on a small project could be a lifesaver and will make working with your code-base better, funnier in every way.

Self code review is incredibly important and efficient. Some might again disagree with this, but I found that reviewing the code changes I did through diffing helped me find possible bugs before I even committed early on. And reading your changes after writing it through diffing will make it easier to find code-smells and readability issues early on. This will even help you find ways to write more efficient and better code with the same functionality more often. If I can't read so the others won't be able either.

Using git has become a genuine fun thing for me over the years. Just as an excuse to play with Git, to help them I often find myself looking for colleagues who are having trouble using Git.

Diffing is life!