Git 101: Initialize a repo and create versions. Link to heading

What is Git? Link to heading

Has this ever happened to you?

Versions mess

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:

Git Basic Workflow

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 statusand 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!