This blog post introduces the fundamental concepts needed to get started with Git/GitHub.

Most of you reading this article have probably heard of Git or GitHub, as they are among the most popular and fundamental tools for working on coding projects. Yet, beginners often get confused about what they are, how they work, and how to use them properly. Hence, this short article series aims to introduce Git and GitHub in the clearest manner to help you get started.
[NOTE]: The structure of the article series is heavily inspired by the tutorial series Git & GitHub Tutorial for Beginners by Net Ninja. If you are unclear about certain concepts and/or want to learn more about the concepts and commands, I recommend checking out the official book.
What Are Git/GitHub?
Git is a distributed version control system created by Linus Torvalds (the creator of the Linux kernel!) used to track changes in project files and create versions that can be restored at any time. It allows multiple developers to collaborate on a project while maintaining their own copies of the codebase.
GitHub, on the other hand, is a platform built on top of Git that hosts project files in the cloud and provides additional collaboration tools. GitHub simplifies the use of Git by offering a web-based graphical interface, making it easier to distribute and manage projects. Without GitHub, developers would need to set up their own remote server for Git hosting.
The above description is deliberately abstract to focus on high-level features, and the details will be revealed as we learn how Git and GitHub work and how to use them. We will start by covering the basic functionalities of Git and then move on to discuss how GitHub fits into the picture. To get started with Git, you need to install it by following the instructions on this official page.
Git Version Control
Git is a tool for managing repositories (repos), which are project folders that we want to keep track of.
It works by placing a hidden .git
directory inside project folders, where all the necessary information
is stored. We can create a Git repository by first creating a project directory using mkdir repo
and then
running the git init
command within the new directory. This should display something like:
Initialized empty Git repository in repo/.git/
. All Git functionalities involve reading from and writing
to the .git
directory within the repository.
Developers create commits, which serve as snapshots of the project history that can be reverted to if needed.
The commit history is stored in the .git
directory. To make it easier for developers to track commits,
each commit must have a unique message. However, before creating a commit, developers must first stage
the changes they want to include, allowing them to commit only specific modifications even after making
multiple large changes to the code.
Staging & Making Commits
To understand staging and committing, we can create two text files within the repository: a.txt
and b.txt
.
Then, we can use the git status
command to check whether Git recognizes the addition of these files.
The output should indicate: Untracked files:
, highlighting the names of the new files in red,
meaning they are not staged yet. To stage a file, we can use git add a.txt
. Running git status
again
should show a Changes to be committed
section, with the staged file names in green. As the message indicates,
you can unstage a file using git rm --cached <filepath>
.

After staging a.txt
, if you modify the file and check the status again, you should see that a.txt
is highlighted in red,
indicating that you must restage the file or discard the recent modifications using git restore <filepath>
.
You can restage the file for demonstration purposes. Here, we want to make separate commits for adding a.txt
and b.txt
,
so that we can later revert to a state with only a.txt
. Therefore, we will stage and commit only a.txt
first.
To commit, use git commit -m "<commit message>"
. The commit message should be informative, like "Added a.txt".
However, before making your first commit, you need to set the author’s name and email using,
git config --global user.name "<name>"
and git config --global user.email "<email>"
.
After setting up the author and making the commit, you should see an output like
[master (root-commit) <commit-id>] <commit-message>
, indicating that the commit was successful.
Now, you can stage b.txt
and commit it using the same commands. After making both commits,
you can use the git log command to view the commit history, including the author, commit message,
commit ID, and date. This history allows us to reference and rewind commits, which will be discussed in the next article.
Conclusion
In this article, we covered the fundamental features of Git and GitHub, how Git manages versions using the .git
directory,
and some basic commands for interacting with it. In the next article, we will continue discussing essential Git concepts
and commands to deepen our understanding and improve our workflow.
Resources
- Net Ninja. 2018. Git & GitHub Tutorial for Beginners #1 - Why Use Git?. YouTube.