Git/GitHub Basics #1 - Getting Started

Last Edited: 1/31/2025

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

DevOps

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>.

Git Example

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