Chapter 02 — Front-End Fundamentals

Git

Every project you build from this point forward lives in a Git repository. Not most projects. All of them. Git is how you track changes, recover from mistakes, and eventually collaborate with other people. It’s also how professional development teams work, which means knowing it is non-negotiable.

This chapter covers enough Git to be useful day-to-day. Branches, remotes, and pull requests come later. Right now you need to understand what Git is tracking and why, and how to make a commit.

Check if Git is installed

Most macOS and Linux machines ship with Git or have it available immediately. Check first:

bash~/tutorials/
git --version

If you get a version number back, you’re set. On macOS, if you get a prompt to install the Xcode Command Line Tools, go ahead and do that. It’s a small install and Git comes with it. On Debian-based Linux (Ubuntu and its derivatives):

bash~/tutorials/
sudo apt install git

Tell Git who you are

Before Git will let you make your first commit, it needs a name and an email address. These get attached to every commit you make, so use something real.

bash~/tutorials/
git config --global user.name "Your Name"
git config --global user.email "you@example.com"

The --global flag sets these for every repository on your machine. You only need to do this once.

Initialize a repository

Navigate back into your tutorials folder from Chapter 1:

bash~/tutorials/
cd ~/tutorials

Then initialize a Git repository:

bash~/tutorials/
git init

You’ll see a message confirming Git has initialized an empty repository. What actually happened: Git created a hidden folder called .git inside tutorials. That folder is where Git stores its entire history of your project. You’ll never touch it directly. Don’t delete it.

Run ls and you won’t see .git because it’s hidden. To see hidden files and folders:

bash~/tutorials/
ls -a

The -a flag means “all,” including hidden items. You’ll see .git in the list alongside your src, dist, and docs folders.

Check the status

git status is the command you’ll run most often. It tells you what Git sees right now: what’s changed, what’s staged, what’s not being tracked.

bash~/tutorials/
git status

Right now you’ll see something like:

plaintext~/tutorials/
On branch main

No commits yet

Untracked files:
  (use "git add <file>..." to include in what will be committed)
        dist/
        docs/
        src/

Git sees the folders you created, but it’s not tracking them yet. That’s what “untracked” means.

What Git doesn’t need to track

Some files have no business being in a repository. Node modules, compiled output, system files, editor configurations, API keys. You tell Git to ignore them with a .gitignore file.

Create one in the root of your tutorials folder:

bash~/tutorials/
touch .gitignore

touch creates an empty file. Open .gitignore in whatever text editor you’re using and add this to start:

plaintext~/tutorials/
# macOS
.DS_Store

# Node
node_modules/

# Build output
dist/

You’ll add to this file as the project grows. For now those three entries cover the most common things that shouldn’t be committed.

Stage your files

Git has a two-step process for recording changes: staging and committing. Staging is where you tell Git which changes to include in the next commit. Committing is where you record them permanently.

This separation is useful. It means you can make five changes and commit three of them, keeping the other two out of that particular snapshot. You’ll appreciate this more as projects get complex.

Stage everything in your project:

bash~/tutorials/
git add .

The . means “everything in the current directory.” Run git status again:

bash~/tutorials/
git status

The output changes. Your files are now listed under “Changes to be committed” instead of “Untracked files.” They’re staged, not yet committed.

Make your first commit

bash~/tutorials/
git commit -m "Initial commit"

The -m flag lets you write your commit message inline. Every commit needs a message. Write something that describes what changed, not how it changed. “Initial commit” is the conventional message for the first one.

Run git status one more time. You’ll see:

plaintext~/tutorials/
On branch main
nothing to commit, working tree clean

Clean working tree means Git sees no differences between your last commit and the current state of your files. That’s the baseline you’ll return to with every commit from here on.

A note on commit messages

You’ll spend a lot of time reading your own commit history. Good messages make that easier. Bad ones make it useless.

“Fixed it” tells you nothing six months later. “Fix nav dropdown closing on outside click” tells you exactly what changed and why you’d look there. Write for your future self.

What you now know

You have a Git repository, a .gitignore, and one commit. In Chapter 3 you’ll install a text editor and open your project inside it. The workflow from here on is the same every time: make a change, stage it, commit it with a clear message.

Reference