Git 101: Initialize a repo and create versions. Link to heading
What is Git? Link to heading
Has this ever happened to you?
It undeniable that files are part of our daily “computer life”, but some times they are a bit complex to work with. This applies to either documentation, source code or that report that our teachers or bosses require (often urgently).
We’ve all been there, trust me, and things don’t get any better when more than one person is involved. You may recall that time when that important file got really messed up after you and your team tried to join each other’s work.
More than once we probably asked ourselves (while crying at the shower in fetal position): is there any better option? Well, what if I told you that there is a way to have one main file (or set of files) to which you can add all the content on a controlled fashion, by setting points in time to which you’re are able to return in case something goes wrong? sounds good, uh? And that’s not all, when working with more than one person, that same mechanism keeps track of the changes each one did and is able to join the parts smoothly (sometimes needing a little help).
Such mechanism exists, it is called Version Control System (VCS). Git is one of them, and probably, the most popular one.
How does it work? Link to heading
When working with Git, you define a set of files that you want to track changes for. Such set of files is called a git repository, or simply a repo.
Then, anytime you make any relevant change or reach a specific milestone, you mark those changes and take a snapshot of the status of the files, in other words, you create a “checkpoint” pointing the current status of your files so that you’re able to return to that state if needed.
These “checkpoints” are called commits and are identified by an unique ID and a short description that tells what a specific commit is about.
The workflow is similar to below figure:
The first thing you need to do is to initialize your repo. After that one time setting, it’s all a matter of marking the changes you want to snapshot and commit them.
To better understand this idea let’s see it in an example.
Git Installation Link to heading
Git is a software you install into your computer. In its most basic form, it’s a command-line tool, but there are some graphical user interfaces available, and some IDEs already integrate with it. In this series of posts, we’re going to focus on learning how to use it from the command line.
Installation is different on each operating system so instead of getting deep into that, I’ll post links to official documentation.
If you’re on OSX or GNU/Linux, after installing Git you can use any Terminal emulator to interact with it. On Windows, the installation includes a separate terminal application that simulates an Unix-like environment. I suggest you to use that one in such case.
Installation links:
To verify that you’ve installed Git correctly open a terminal and type:
git --version
If you’re able to see the version of Git installed thren you’re good to go. If not check the installation steps again.
A Basic Git Workflow Link to heading
Let’s start by making a simple web project.
Create a new directory and open a terminal inside of it. We’ll initialize this folder as a repo
by typing:
git init
This command will create a new folder (If you’re on Linux or Mac the folder will be hidden). That’s the .git
folder, where all the repo configuration, metadata and version will be stored. You’ll rarely need to mess with this folder but it’s good to know about it.
Now let’s add some code to our project. Create a new public
folder, and inside of it create the index.html
as follows:
<!DOCTYPE html>
<html>
<head>
<title>Git is awesome</title>
</head>
<body>
<h1>Git is awesome</h1>
<p>Let me show you how Git can really change thet way you develop your applications</p>
</body>
</html>
The next step is to commit
these changes. The first thing we need to do is to mark which are the changes we want to commit. To do so we use the add
command followed by the file to save.
In the terminal, type:
git add public/index.html
In this way we’re telling Git: “I want you to get ready to take a snapshot of the state of this file”.
To know what is the current state of the repo, we can use the status
command. In the terminal type git status
and you should see something like this:
On branch master
No commits yet
Changes to be committed:
(use "git rm --cached <file>..." to unstage)
new file: public/index.html
The output is telling us the following things
- “On branch main”: This is the current branch (we’ll talk about branches in a future posts, for now think of them as variations of the same repo that coexist along the main one)
- “No commits yet”: This means that currently there aren’t any commits or versions created.
- “Changes to be commited”: Shows the lists of changes that are going to be commited, and what types of changes they are. If for some reason there is a change that you son’t want to commit, it also shows you the command you’ll need to type to remove such change.
Ok, everything seems right, so let’s commit these changes. To create a new commit we use the commit
command (You didn’t see that coming, right? 😆) followed by the -m
and a short description about the changes you’re commiting.
Why is that important? Commits are identified by a random string. When you have a bunch of them and want to return to a specific point in time you’ll need something to give you an idea of what was the status of the file at a given point in time, so that’s why is a good idea to add a description.
In this case, only thing we did was create a file, so let’s type:
git commit -m 'added index.html file'
And just like that we have the first version of our repo!
Let’s add one more change to get the idea.
Let’s say the client you’re creating this website for didn’t like the adjective “awesome”, and wants something more in line with younger generations. Modify index.html
as shown below.
...
<head>
<title>Git is Gas!</title>
</head>
<body>
<h1>Git is Gas!</h1>
...
Now you can add these changes by following the same git add
& git commit
set of commands.
Pro-tip: you can add multiple files in the git add
command by writing their names separated by spaces, or all the files in the current folder by writing .
.
Now you have the first two versions of your repo!
Moving Through Versions Link to heading
Now let’s say that your client found out that using Gen Z slang in their Millenial-targeted product’s website was not a good idea, and wants you to get it back to what it was before.
In this particular example, it’s only a matter of a little rewriting here and there, but that’s not the case for real world scenarios. So let’ s see how you can use Git to easily getting back to a previous version without rewriting anything.
First, list out the versions you have available like this:
git log
You’ll get an output that looks like this:
commit f8aa93d540daf7bee66fa099a9ee142ffa850ac7 (HEAD -> main)
Author: Hector Zelaya <inge.zelaya@gmail.com>
Date: Tue Jan 14 17:17:32 2025 -0600
made website more in line with younger generations
commit e766349379887b9edfb2cf96ae4b702884f92348
Author: Hector Zelaya <inge.zelaya@gmail.com>
Date: Tue Jan 14 17:16:27 2025 -0600
added index.html file
You can see that you have two snapshots or versions of your repo: one taken right after adding the index.html file, and another one after that lame attempt of trying to make it fit with zoomers.
Now, let’ s say that you want to return back to the first version of your repo. You can do it by using git checkout
followed by the commit id (in this case e766349379887b9edfb2cf96ae4b702884f92348
).
git checkout e766349379887b9edfb2cf96ae4b702884f92348
Note: switching to 'e766349379887b9edfb2cf96ae4b702884f92348'.
You are in 'detached HEAD' state. You can look around, make experimental
changes and commit them, and you can discard any commits you make in this
state without impacting any branches by switching back to a branch.
If you want to create a new branch to retain commits you create, you may
do so (now or later) by using -c with the switch command. Example:
git switch -c <new-branch-name>
Or undo this operation with:
git switch -
Turn off this advice by setting config variable advice.detachedHead to false
HEAD is now at e766349 added index.html file
And now if you take a look at your repo, you’ll see that it’s back to the first version!
Recap Link to heading
So we just covered the basics of Git: we created a repo, added files and committed them, then moved through versions. We also saw how to use git checkout
to return back to previous versions. However the real power of Git comes when you start using branches, which will be covered in a future post, so stay tuned!