How to Use Git – First Part

Don’t have a clue what Git is? Do you think it’s the name of Elon Musk’s new car? Do you need it for your new project of OS class? There’s nothing to worry about: just follow this step-by-step introductory guide and you’ll soon be familiar enough with Git to brag to friends and family that you’re a developer™.

Before we delve deeper, let’s clear up a common misconception: Git is not the same thing as GitHub. Git is a version control system (i.e., a piece of software) that helps you keep track of the programs and files on your computer and the changes that are made to them over time. It also allows you to collaborate with your colleagues on a program, code or file. GitHub and similar services (including GitLab and BitBucket) are websites that host a Git server program to hold your code.

What is version control?

Version control is the practice of tracking and managing changes to software code. Version control systems are software tools that help software teams manage changes to source code over time. As development environments accelerate, version control systems help software teams work faster and smarter.

For example, suppose your teammate is working on a certain feature on a project, while you’re busy rewriting another feature. When the work is done, if we wanted to merge the changes from your partner and your work, we would normally have to compare the two files and manually copy/paste/move them. Besides the loss of time and efficiency, the process is not always the best since humans often make mistakes. Version control, on the other hand, allows you to easily manage different versions of your source code without worrying about conflicts and/or replacement.


Git (British slang for “idiot”) is version control software, initially developed in 2005 by Linus Torvalds. After experimenting with proprietary version control systems, Linus sought to develop a new, high-performance open-source system from scratch to facilitate his work in patching the Linux kernel.

The main difference between Git and any other VCS (Subversion and friends included) is the way Git thinks about its data. Conceptually, most other systems store information as a list of file-based changes. These other systems (CVS, Subversion, Perforce, Bazaar, and so on) treat the information they store as a set of files and the changes made to each file over time (this is commonly described as delta file-based version control).

Git doesn’t store its data in this way. Instead, Git thinks of its data more like a series of snapshots of a miniature filesystem. Whenever you commit or save the state of your project, Git basically takes a picture of what all your files look like at that moment and stores a reference to that snapshot (in technical jargon, commit). To be efficient, if the files haven’t changed, Git doesn’t store the file again, just a link to the identical previous file it has already stored.

Think of the commit as a picture of our project. This object also contains the name and email of the author, the message you typed (often it’s the description of the commit), and pointers to the commit or commits that came directly before this commit (its parent(s)). A branch in Git is simply a lightweight pointer to one of these commits. The default branch name in Git is master (or to be more politically correct main). When you start committing, you’re assigned a master branch that points to the last commit you made. Whenever you commit to the branch, it automatically moves forward. We’ll tackle the branching part in more detail in Part 2.

In the next few paragraphs, we’ll introduce the first commands to get you familiar with Git and how to make your first commit directly to the main branch.

Cloning a new repository

To clone a new repository, simply use:

git clone URL_REPO

where URL_REPO is the link to the repository. In our example, the repository will be called first-repo.

Git Status

The git status command is very useful to check the status of our repository. It returns to the user a whole bunch of information about untracked files, which files are ready to commit and which ones have been modified. It’s very useful the first few times to actually understand what we include within a commit and what we don’t.

Adding files for editing

Once we’ve cloned our empty repository and written some code, we need to notify Git of the presence of new files that we want to track for the next commit. For example, if we have the src folder with the main.c file inside, we can directly add the src folder (and all the files inside this folder) through the command:

git add src/

Git’s output returns all the files added to the tracking and can be run multiple times before a commit. It only adds the contents of the files specified when the add command is executed. (So any other changes made after the add command are not tracked in the commit). All traced files go into the so-called staging area, ready to be committed within the repository.

In git, it’s not possible to track empty directories. One of the many workarounds is to create an empty file inside the folder using the touch .gitkeep command.

If the files have already been “tracked” previously (that is, if Git already has some information about the structure of your repo) and we want to update the file contents, simply call the git add -u command: Git will evaluate every file whose path it already has. If we were to call git add folder_name for each change, git would perform a rather time- and resource-intensive index to the folder_name folder.


Now that the staging area is set up the way you want it, you can commit your changes. Remember that anything not yet in the staging area (any files you created or edited that you didn’t run git add on when you edited them) will not go into this commit, but will remain as edited files on disk.

To commit, simply run this command:

git commit -m "Comprehensive message about what I've committed"

where the -m (--message) flag indicates the message that will be included in the commit. It is often a good idea to include a brief description of the changes or additions to the various files in the commit message.

Uploading Files

To upload files remotely, we run the following command where branch_name is the name of the branch we want to upload the commit to.

git push origin branch_name

Often this kind of command requires authentication (Basic or via token).