Learning the Git Basics — a Crash Course

25 min readApr 25, 2021

When we think about Git, we usually picture complex ecosystems of parallel working threads which diverge and converge at certain points in time. While difficult situations will be encountered when you use Git, this guide will deconstruct some of the basic concepts related to Git, thus creating a bridge or understanding for the harder concepts.

– Motivation
– What is Git?
– Prerequisites
– GUI VS CLI
– Commands breakdown
– Git storage areas
– The .gitignore
– The Git encryption algorithm, trees and blobs
– Branching and parallel work
– Merging and conflict resolution
– Time travelling through the project
– Git work models and forking
– Git good practices & advantages
– The learning curve
– Conclusion

Motivation

A few years ago while I first started working with git, I decided to aggregate all information I found relevant into a document. That document then became this introduction guide.

It has been staying idle in my document archive for some time now and I just recently stumbled upon it again.

The reason for publishing it now is that it condensed a few dozen hours worth of tutorials and documents into a few pages. It has both theoretical explanation and practical exercises. If it reaches only a few people and helps them in any way, then it has served its purpose.

While some concepts are over simplified, I don’t think that is an impediment. For deeper dives into the topic there are great resources available like the git documentation and their free git pro book.

What is Git?

Git is the most popular version control system in the world at this time.

It enables us to easily manage our work remotely as well as offline. Because of this reason and also other major strengths we will explore throughout the article, it has become an extremely popular tool in the past few years. Out of the total users working with version control systems, Git users represented 11% in 2010 and reached a staggering 70% in August 2019 (statistics from this thread).

Why has it gained so much terrain?

The reason is pretty straight forward: it’s well designed, optimised, secure and relatively easy to use. Its flexibility casually surpasses that of its predecessors.

There are tons of learning materials on this topic available on the web but here’s my attempt to explain the concept with this document using a combination of action items + explanations. My approach is to break the most important concept down into multiple smaller pieces. Then, discuss each individual piece and see how it all binds together. This will create a nice whole, offering you a more complete understanding of Git.

Throughout the article you will see some paragraphs marked with the ‘🕹️’ unicode character. Wherever you see this it means that you should perform some action (install, create files, run console command, etc) in order to keep up with the article’s progression.

We are going to scratch the surface of Git and cover topics like:

Which should I use? The CLI or a GUI when it comes to Git.
Explore the differnt type of commands.
Explore the storage areas which Git uses to manage a project.
See why the .gitignore file is useful and how we can set it up.
Explain each Git object.
Understand branches.
See how to merge branches and resolve conflicts.
Time travel through a project.
Explore various working models for Git and see what forks are.
Talk about some Git good practices.

Prerequisites

In order to complete and better understand all the steps presented in this document, Git needs to be installed.

🕹️ You need to download Git from here and go through the installation process.

If you encounter any difficulties, the official website shows how to install it on all major operating systems. The documentation can be found here.

🕹️ Open the terminal (Mac/ Unix OS) or command line (windows OS) and run the git --version command. If you are displayed a message with the Git version you can continue, if not, revert to the previous installation step and redo it.

Assuming we all have Git installed, we can go on.

GUI VS CLI

When it comes to the way we want to interact with Git, there are 2 options: using a graphical user interface (GUI) or a command line interface (CLI). There are advantages to both approaches but I personally favor the latter. The reason is that when it comes to graphical user interfaces, they might differ from one app to another. While changes might not be drastic, particularities of each system might confuse a normal user who is familiar with another system.

This issue doesn’t exist if we use a command line interface. By using this approach you make sure that you can use Git on any OS without being concerned with insignificant particularities of various GUI apps. The command line gives you access to 100 % of Git’s features while a GUI tool might fail short when it comes to addressing some corner cases. In that situation, you would have to revert to the command line anyway to solve a particular issue. Besides that, most solutions explored on various sites like stack overflow present CLI approaches.

Git also comes with some GUI elements but we will explore this further along the article.

The final argument to why you should be using the command line is that if you possess this knowledge, shifting to other distributed version control systems like Mercurial is easy. The principles and commands are mostly the same.

Commands breakdown

In the context of a software development firm, at some point we probably interacted with Git. This interaction might have been using a GUI or CLI where we followed some steps as they were presented to us.

These steps most likely involved some porcelain commands which are low level, human readable commands (add, pull, push, commit, etc). On the other side of the spectrum there’s the high level command called plumbing commands (cat-file, checkout-index, diff-files, etc) which are usually designed to be handled by more experienced users and satisfy more complex scenarios.

Both types of commands will be used throughout this article. To be noted that the command names are not the important part, we don’t have to memorise them all. We can always use cheat sheets like this one which is beautifully compiled by the guys at Github (which should not be mistaken for Git, they are different applications).

What is important is understanding the model and how everything works.

Git storage areas

Git is designed in such a manner that it works with 4 storage areas. Understanding how your files move within these 4 areas is vital to breaking down how Git works.

1. The working area

This is where you keep all your files and folders from a project. Whether it’s a batch of .css, .html, .js files corresponding to a working application, some .java files for some automated tests or any other files from this category, it doesn’t matter for Git. It analyses their content and moves them to the area we tell it to.

🕹️ Let’s start by creating a folder named ‘GitProjectPractice’.

🕹️ Inside this folder, create a text document ‘ExampleDocument.txt’

🕹️ Add the following text on the first line if the .txt file: ‘This will be easy to learn!’

You now have a perfectly valid working area. Congrats!

2. The repository

The repository contains the entire history of the project. Whenever you make a change to your project and you commit it (which basically tells Git to remember a change), the history is updated and associated to the .git area of the project. Basically all stages of your project’s life are mapped out here.

All these changes are kept in a very well optimised database structure which grows as your activity on the project intensifies.

The problem in our situation is that we don’t have a .git area anywhere. This means we don’t have an actual repository yet, we have to create one. To do this we need to initialise the actual Git repository. :

🕹️ Change the current directory to your ‘GitProjectPractice’ folder in the cmd/terminal using ‘cd path/to/GitProjectPractice’

🕹️ Run git init

to initialize the existing directory as a Git repository

This will create the .git file which will store from now on all changes you make on your project. If you by any chance don’t see this file, one of two things happened:

You initialised the Git repository in another folder than you were supposed to
The .git folder is hidden and you have to change the folder options to view the hidden files and folders

By now, our project should look something like this:

Now, the history of the Git repo is empty. Think of it kind of like the Chrome browser. It tracks everything you do, the pages you navigate, and you can view the history afterwards. The only difference is that, unlike Chrome, it doesn’t automatically track all your actions. Instead, you have to tell Git what you want to track and what not.

The changes you made to the working area don’t show up anywhere. We have to specifically tell Git that we want to track them.

As I mentioned at the start of the repository section, the history is updated when we do a commit with a certain change.

What is a commit you might ask? Roughly put, a commit is a block of information.

🕹️ To make a commit, we have to use the following command in the command line:

git commit -m "The first commit in this repository"

This command means that we are trying to add the changes made to the ‘GitProjectPractice’ folder (creating and editing the ‘ExampleDocument.txt’ file) to the repository history and associate a certain message with our commit (-m “my message”)

The problem is, Git can’t do that just yet. As the console error message suggests, there is ‘nothing added to commit but untracked files present’. This takes us to the next storage area:

3. The staging area (or index)

This is the place where you have to put all your files before you actually commit them. It’s an intermediate between the working area and the repository. In order to see which changes have not been added to the intermediate space we have to use the following command:

🕹️ Run git status

in our situation we can see the ‘ExampleDocument.txt.’ has been added and modified and its changes don’t appear in the history.

This takes us to the next step where we actually have to add the file to the index using:

🕹️ Run git add ExampleDocument.txt

in a more general context it would have beengit add "filename.extension"

If we had more files to stage, we would have run this command for each of them. Alternatively, if we wanted to add all files, we would have run the command:

🕹️ git add . –the dot (.) signifies a wildcard which means ‘all files’.

Now that we have all our changes added to the staging area, we can finally put them in the Git repository and the history using the:

🕹️ git commit -m "The first commit in this repository"

**Add to Index and Commit to Repository**

At any moment we can unstage changes (remove them from the index area) by using the command git rm --cached filename.extension. Let’s try this.

🕹️ First, add another file to your working directory, this time a .html file named ‘WebPage.html’ for example.

🕹️ Edit the .html file and add the following code:

<HTML><HEAD><TITLE>Your Title Here</TITLE></HEAD><BODY BGCOLOR=”FFFFFF”><CENTER><IMG SRC=”https://cl.ly/2N193b0R0U3v/Git-Logo-2Color.png" ALIGN=”BOTTOM” width=”10%” > </CENTER><HR><a href=”https://git-scm.com/">Link Name</a>is a link to another nifty site<H1>This is a Header</H1><H2>This is a Medium Header</H2>Send me mail at <a href=”mailto:support@yourcompany.com”>support@yourcompany.com</a>.<P> This is a new paragraph!<P> <B>This is a new paragraph!</B><BR> <B><I>This is a new sentence without a paragraph break, in bold italics.</I></B><HR></BODY></HTML>

🕹️ Track the change to your working directory with git add WebPage.html

🕹️ Inspect the status of your current directory with git status

This shows us that the change has been staged

🕹️ Remove the file from the index with git rm ––cached WebPage.html

🕹️ Run the git status command again and notice that the file appears as untracked again. This means you can only find it in the working directory not in the index.

🕹️ Let’s add this file to the repo as well using git add then git commit -m "Added v1 of a .html file for the landing page"

If you opened the static web page you just created, it should look something like this:

If everything went well, we now have two commits. Now we can talk about the final storage area:

4. The stash

This is a temporary staging area. You can view it as a clipboard so to say. A use case for the stash is when you’re working on something and in the middle of your work, an urgent task appears and you have to work on that instead.

What you were working on is not yet functional and you cannot use it yet so you have to store the progress somewhere, then start working on a task with a higher priority. The stash is an important part of Git but we won’t be talking about it too much in this article.

You should, for know, know that you can ‘stash’ unfinished work in this area without having to create additional commits. Then, resume that unfinished work whenever you choose to.

An oversimplified representation of these 4 areas can be found below:

Before we move to the next section, it is important to note in the same manner we move files into a certain working area, we can also remove them from that area, or edit certain aspects before moving the files again.

The .gitignore

Git uses the .gitignore file to determine while files and folders will not be included in our commits. This file is generally created and defined at the beginning of the project and updated throughout the project’s lifetime to include new rules depending on the needs.

Common files which should be ignored are build artifacts and machine generated files like dependency caches, compiled code, logs and temporary files (.log or .tmp files), hidden files such as the .DS_Store and personal configuration parameters of the project (IDE config files, environment variables which are specific to our own working machine, etc).

Now let’s build our own .gitignore file and define it for our current project.

The first step is to create the file:

On Unix systems:

🕹️ Run touch .gitignore in our current working area

On Windows systems:

🕹️ Run type nul > .gitignore

The second step is to define what we want to ignore:

🕹️ Open the .gitignore file using a text editor and add the following lines:

# Logs and databases #*.log# OS generated files #.DS_Store.Trashes*.orig

The last step is to add the file to the index and commit it to the repo using:

🕹️ git add . then git commit -m "Added the .gitignore file"

The Git encryption algorithm, trees and blobs

For Git, the files we work with are just a sum of keys and values. Values are attributed to those keys, just like the structure in a JSON file. The values in this case represent a sequence of bytes.

Conceptually, when you make a change to a file, git stores that version of the file and uses a hash as its name. The SHA-1 algorithm is used to achieve this. Every chunk representing some content in our project has its own SHA1 hash in a format similar to ‘d670460b4b4aece5915caf5c68d12f560a9fe3e4’. You can then use these unique keys to retrieve the content attributed to it.

To illustrate this, let’s encrypt a simple String type value using the SHA1 algorithm. To do this use the following command in the terminal:

🕹️ echo "Some random string" | git hash-object --stdin -w

The output of this command is a hash. Now let’s say that we want to see the content of that key. To do this we need to run the following command:

🕹️ git cat-file -p hashValue (‘hash’ will be replaced with the generated value from the previous command’

Voila! The output is the initial string we used. Git manages all its content in this manner. Everything is converted to SHA1 hash references.

Using the cat-file command we can also deconstruct a commit and see its content. We get to see the name of the author, the committer, the commit parent, the commit message and the commit tree. Let’s try to deconstruct our last commit and see some details about it:

🕹️ run git log

which will show us all our commit history from the current project.

Each commit has a unique hash which we can use for the deconstruction process.

🕹️ copy the hash of the commit which added the .gitignore file

🕹️ run git cat-file -p copiedHash

and inspect the results => we will see a tree, a parent, author, a committer and a commit message:

Let’s go a level deeper and inspect what the tree contains:

🕹️ run git cat-file -p treeHash

and inspect the results => we will see 3 files (the initial text file, the .html page and the .gitignore). Notice that they have the word ‘blob’ before the hash. We will explain that term in a bit.

We can go even deeper and inspect each of these files and see what they contain.

Along with commits, trees represent Git objects. We already established what a commit is so let’s see what trees are.

To put it plainly, a tree is a directory which contains other trees (subdirectories) and files. The content of a file (file which is found inside a tree) is called a blob (binary large object) which is another git object.

Let’s summarize this section which was a bit more complicated:

A commit has a parent. That parent embodies the content/ structure of the project before the child commit. This means that a commit will always point towards another commit (except for the initial commit which doesn’t have a parent).
That commit also points to a tree which has the same content as the parent plus some modifications to the content/ structure of the project.
A tree points to all items present in the project at that point in time.
A tree can contain other trees and blobs.
File names and file permissions are stored in the tree and not in the blob which only stores the content of the file.

Branching and parallel work

As soon as you made your first commit, you also created the project’s first branch. This is the popular master branch.

The most basic definition is that a branch is a reference which points to a particular commit. Based on the documentations from Atlassian, branches are referred to as ‘independent lines of development’. Combining these 2 definitions we can safely say that a branch starts out as a reference to a commit and is later continued or enhanced by a chain of additional commits.

🕹️ to create a new branch run ‘git branch htmlExperiment’

Currently, we have 2 branches which are equal when it comes to content.

🕹️ in order to see all existing branches run git branch

The branch which we’re currently working on is marked by an asterix (*).

Before we start working on the newly created branch, let’s edit the image url for the html page:

🕹️ change the URL from the <CENTER><IMG SRC=”https://cl.ly/2N193b0R0U3v/Git-Logo-2Color.png" ALIGN=”BOTTOM” width=”10%” > </CENTER> section with any different URL which points to an image

🕹️ open the ‘WebPage.html’ file in the browser to see if the changes are OK

🕹️ add and commit the changes

Now we have a stable version of the web page. Let’s assume that we want to do some experimenting but we don’t want to risk breaking anything on the stable version. So we need to move to the experiment branch and do our changes there.

🕹️ to do this run git checkout htmlExperiment

If we are to open the .html file now, we can see that the changes we previously made are not visible. This is because this version of the project was created before modifying the image URL.The experiment we will do consists of something very simple which we are going to use in the next section:

🕹️ change the URL from the .html file with an entirely new image (can be anything from the web)

🕹️ add and commit the changes

We now have 2 different branches, each with a .html page different from the other. At any time we can checkout either of those branches and see how the .html page looks for each version. We can also view the differences between the 2 branches:

🕹️ run git diff master

If we were on the master branch we would have had to run git diff htmlExperiment

The result is that Git shows us that the URL for the image on the master branch is different than the URL on the htmlExperiment branch:

In the context of branching, it is also important to mention the HEAD element. Think of the HEAD as a reference pointing towards the last commit from your current branch. If you switch to another branch, the HEAD will also move there. It is basically a node with no other nodes pointing towards it.

This concept is very thoroughly explained and well organised in an introductory course by Paolo Perrotta — How Git works available on the learning platform Pluralsight. I also recommend this course to anyone starting with Git and willing to spend 2–3 hours on it.

Merging and conflict resolution

In a normal situation, after an experiment or a feature has been completed on a branch, we need to update the master branch with the new code found on the experiment branch.

This scenario sometimes generates conflicts, because it’s not just you working on the project. There are multiple people involved and it happens that more people worked on the same file.

For our scenario, we now want to merge the master branch with the htmlExperiment branch. Let’s switch back to the master branch and bring the changes from the experiment branch there:

🕹️ run git checkout master

🕹️ run git merge htmlExperiment

Git first tries to perform and auto-merge. This works if there are no conflicts, but in our situation, we will have a conflict since we worked on the same item in both branches. The error message states:

‘CONFLICT (content): Merge conflict in WebPage.htmlAutomatic merge failed; fix conflicts and then commit the result.’

We need to now solve the conflict. There are multiple ways to do so one of them being the mergetool which opens a text editor in the command line:

🕹️ run git mergetool

We should see something like this:

The interface looks a bit scary and unfriendly at first but once you get a hang of it it’s easy to manipulate. It’s basically a command line text editor.

The screen is divided in 4 sections:

The upper-left section is the version of the file where we changed the initial header image in the master branch
The upper-right section is the version of the file where we changed the header image on the experiment branch
The upper-center section is the version of the file before we made the changes displayed in points 1. And 2.
The bottom section of the screen is where we will do our editing of the file and we will see what the file will look like after we have solved the conflicts

If you have experience with ‘vim’ or ‘vi’ or other Unix type command line editors it will be a piece of cake. If not, we’ll take it step by step (you won’t need to use your mouse):

🕹️ first we need to open the edit mode by pressing the ‘a’ or ‘i’ key from the keyboard

You will know you are in edit mode if you see the ‘ — INSERT — ’ text at the bottom of the terminal/ cmd

🕹️ next you need to inspect the changes and decide which ones you want to keep

In our case the changes are shown side by side in the following format:

<<<<<<< HEAD<CENTER><IMG SRC=”https://cl.ly/2N193b0R0U3v/Git-Logo-2Color.png" ALIGN=”BOTTOM” width=”10%” > </CENTER>=======<CENTER><IMG SRC=”https://cl.ly/2N193b0R0U3v/Git-Logo-2Color.pngz” ALIGN=”BOTTOM” width=”10%” > </CENTER>>>>>>>> htmlExperiment

When it comes to the information overlap, everything marked with red is what we have in the ‘master’ branch and everything after, marked with green, is contained on the ‘htmlExperiment’ branch. Let’s say we decide to keep the changes from the experiment branch. This means we have to:

🕹️ delete the following sections:

<<<<<<< HEAD<CENTER><IMG SRC=”https://cl.ly/2N193b0R0U3v/Git-Logo-100Color.pngz" ALIGN=”BOTTOM” width=”10%” > </CENTER>=======>>>>>>> htmlExperiment

This means that we are discarding the line of code with the image we have added on the ‘htmlExperiment’ branch (what was marked with green). We will be sticking with the image version which was added to the stable version (master).

🕹️ now we need to exit edit mode by pressing ‘Esc’

🕹️ then save the changes and quit the editor by typing ‘:wq’ + Enter

After this, the editor will be closed (bottom part of the command line).

🕹️ We have to manually close all other screens using the command ‘:q’ repeatedly

There are a lot of mergetools available on the web. It’s up to you to decide which works best for you. If you decide to use any vim based editor, check out the vim commands cheat sheet here.

Now that a new change has been made, we have to commit it:

🕹️ run git commit -m "commit after merging functionalities x and y"

This will basically create a new commit or node which will point towards 2 other commits: the commit from the ‘master’ branch and the commit from the ‘htmlExperiment’ branch. This means that, unlike all our other commits up until this point, this last one will have 2 parents.

There is another way of performing a merge, using rebase. In very broad terms, rebase does approximately the same thing as a merge with the difference that rebase distorts the commit history. This makes it harder for us to follow the timeline of a project since our commit history will look linear. There are advantages and disadvantages to both approaches but that is a topic for another time.

See a brief visual representations of merge & rebase below:

Time travelling through the project

Commits are portals for time travelling throughout different versions of the project. This is the whole point of versioning.

For example, if some code or files were accidentally deleted on the latest version of the project, we can just leap back in time on a previous commit and fetch our missing files from there.

In order to see a detailed history of what happened, you don’t necessarily need a GUI tool which shows pretty pictures of branches and changes which occured over time. We have 2 ways of managing this feat from Git directly:

🕹️ run git log --graph --decorate --oneline

For the current project, if all steps were completed successfully, this command should generate a command line ‘graph’ very similar to the one displayed below:

🕹️ run gitk

to see a more detailed view of the graph generated during the previous command

You can perform a checkout of an old commit, for example the commit before adding the .gitignore file and see how the working directory looked in that stage of the project

🕹️ run git checkout hashBeforeGitignoreCommit

🕹️ run git checkout master

to revert back to the latest version of the project

Git work models and forking

Repositories can be classified broadly into local repositories and cloud repositories. So far, by following the steps in this document, you have only worked with a local repository. If you were to upload that local repo somewhere, into platforms like Bitbucket or Github, you would also have a cloud repository which you can share with other people.

Based on the type of repo and interactions between the owners of the repositories, we can have multiple models:

1. Peer to peer model

Let’s imagine we have a team of 3 people working on the same project. If they decide to use the peer to peer model then they each have their own local repos which have the same base but with various additions depending on what each person is working on.

In this case, all repositories are equal and the workflow becomes a bit tedious. This happens because each person has to continuously fetch the changes made by their colleagues, and a high level of communication is required in order for this model to work properly.

The next image shows a very basic representation of this model. The arrows represent the direction data is ‘flowing’ towards.

2. Centralized model

The same 3 people have their own local repos like in the previous model, the only difference being that there is yet another ‘central’ repository where they pull or push changes from/to. The central repo is also called ‘origin’ because this is the default name given by Git when we clone a project from another repository. It can also be referred to as the ‘blessed repository’.

In the following illustration, the ‘blessed repo’ is showcased as being somewhere in the cloud.

3. Pull request model

This model is very similar to the previous one, the difference being that only one person has permissions to write or merge data directly to the central repo. In this case, that person also has access to the other 2 working repos where he can see, review and fetch changes, then push them to the centralised repo.

If one of the 2 people who don’t have access to write information to the central repo wants to make a change to the ‘origin’, then they first have to issue a message to the person with write permissions who will later do a push. This message is called a ‘pull request’.

The following image illustrates this example in an over simplified manner, where only the person operating ‘Machine 2’ can push changes to the central repo. The other team member must issue a pull request to the user of ‘Machine 2’, wait for his changes to be reviewed and then get the updates on the central repo if everything was fine.

The dashed line represents a pull request where the person operating Machine 2 fetches the updates from Machine 1 or Machine 3 and reviews them. The person operating Machine 2 in this case, is often referred to as a ‘maintainer’.

4. Dictator-lieutenants model

This is an extended version of the pull request model. It’s usually used on large projects which make it very difficult for a single team to maintain. A popular example for this model is the Linux kernel project.

In the following image example, you have a large project. This large project is ‘supervised’ by its maintainer who is the astronaut figure at the top most layer.

There are also 2 sub-projects each with their own maintainers (the ninja figures). At the bottom most layer we have general contributors who can push changes to be reviewed by maintainers on the upper levels.

As we mentioned before, repositories can be kept locally or in the cloud. Knowing this and the models used working with repositories, it’s easier for us to understand what a fork is.

Forks

A fork implies that you first clone an open-source project (get all code locally). Then, make some changes to that project (or not). And then, the final step is when you upload the updated project into a cloud repo different from the source. You have now successfully created a fork.

If you want to experiment how working with cloud repositories would work, register a free account on Bitbucket or Github, create a new repo there and Bitbucket will guide you through the process of getting your local Git repository up in the cloud.

Git good practices & advantages

Some good practices are:

Having a clean history is important. The quality of the history is dictated partly by the quality of the commits. Each project is different but there are a few widespread ideas regarding commits we should keep in mind when working with Git.
Commit early and often.
Don’t change published history.
Update your local repo periodically
A good practice is when you commit something to add a commit description as well as a detailed commit message like ‘git commit -m “Short summary of what the commit contains” -m “Some detailed information on the commit at hand”’.
Changes attributed to a commit should be related and not spread across multiple commits. Also, a single commit should not have multiple unrelated functionalities and changes crammed up.
Each commit must leave the code in a working state. This means that there should be no errors or failing tests.
When it comes to defining a branching model, it’s hard to go on the web and find a predefined model which would match your project workflow exactly. Each project is different and there is no ‘best’ model you should implement. There are very famous models like GitFlow which have been widely used and fit a variety of projects. That doesn’t necessarily mean it fits your needs exactly. You can use it as an inspiration and design a new version which works for your team.

Some advantages for using Git are:

Everything in Git is cost efficient and optimised.
Revert mistakes easily.
Resume work at any time and on any computer.
Sync everything.
Free.
Simultaneous development.
Support for all major development environments and operating systems.
Large community with vast amounts of resources.

The learning curve

If we start using Git without having too much knowledge about what happens ‘behind the curtains’ and we just go through what we were told we were supposed to do, the learning curve is pretty linear.

On the other hand, as soon as we start investigating and we understand how it works, the learning curve becomes more steep and we can venture into features which otherwise would have been really hard to comprehend.

If you want to get more acquainted with the words used in Git terminology, I recommend reading this glossary. It will help you enrich your Git vocabulary and understanding and fluidize any potential Git related conversation.

In conclusion…

At the present time, Git is by far the most powerful DVCS. This is due to its simplicity, efficiency and optimisation and this will most likely not change in the near future.

From a tester’s perspective, this is a strong argument to why we should strive to understand as much as possible about this topic. This is valid especially in the current context of the IT world where the role of a tester is a mix between technical knowledge and other non-technical aspects like understanding the business and our client’s needs and struggles. Attaining such understanding creates a bridge between these 2 worlds which facilitates communication.