Understanding Git: The Foundation for GitHub Actions

Introduction

It’s 2 AM. You’ve finally fixed that bug after hours of debugging. You hit save, refresh the browser and… nothing works. Not just your new feature - the entire homepage is blank. Your stomach drops. Which file did you just edit? What was the working version? Your demo is at 9 AM.

Or maybe your teammate just messaged: “I fixed the login system!” But you’ve been rewriting the same files for the past three hours. Now whose code survives? Do you lose your work or delete theirs?

We’ve all been there. But what if you never had to experience that sinking feeling again?

Hey everyone, 👋 and welcome to the first article in our series on modern software development! Today we’re diving into Git - the version control system that’s become the foundation for platforms like GitHub and services like GitHub Actions.

If you’ve ever written code and worried about breaking it, this guide is for you. No prior knowledge of version control needed - we’re starting from absolute zero.

Git helps you to:

• Restore any previous version of your code in under 10 seconds
• Turn 3 hours of debugging into a single undo command
• Merge teammate changes without losing anyone’s work
• Build reliable, automated workflows later using GitHub Actions

In this beginner-friendly guide, you’ll learn how to:

• Set up Git and create your first trackable project in under 5 minutes
• Save code changes with meaningful checkpoints
• Navigate your project’s history like a time machine
• Recover from any coding disaster with confidence
• Understand Git’s role in modern software workflows

By the end of this article, you’ll have a Git repository with at least 3 commits and the confidence to recover from any mistake.

We’re starting from scratch - so no prior experience is needed. While Git might seem intimidating at first, by breaking it down step-by-step, you’ll be surprised how quickly it clicks. We’ll explain not just how Git works, but also why it’s so important for any software project.

Every day your code sits unprotected is another day risking everything you’ve built. Ready to code with confidence? Let’s start with understanding the real problems Git solves - problems you’ve probably faced just this week…

Enter Git: Your Code’s Safety Net

Remember that stomach-dropping moment we just described? You’re not alone - every developer has been there. In fact, this problem was so universal that it sparked the creation of Git, now used to protect everything from tiny personal projects to massive codebases like the Linux kernel and Windows itself.

So what exactly is Git? It’s a version control system that tracks every change to your code, creating a complete history you can navigate, search, and restore from at any time. Think of it as an unlimited undo button with a time machine attached - every save point is preserved forever, ready to rescue you when things go wrong.

The same tool that Microsoft uses to manage Windows, that Google uses for Android, is about to solve your 2 AM disasters forever. Let’s get it on your computer and see this magic in action - installation takes less than 5 minutes.

Installing Git in Under 5 Minutes

First, let’s install Git. Choose your operating system below:

[!NOTE] We’ll be using the terminal/command line - don’t worry if you’ve never used it before. Just copy and paste these commands exactly as shown.

Windows:

1. Download the installer from git-scm.com
2. Run the installer and accept the default settings
3. You’ll get “Git Bash” - a special terminal for Git commands

[!IMPORTANT] Windows Users: Throughout this tutorial, use Git Bash (not Command Prompt or PowerShell). After installation, find it by searching “Git Bash” in your Start menu. All our commands are designed for Git Bash. If you’re using Windows Subsystem for Linux (WSL), you can use that instead of Git Bash for this tutorial.

macOS: If you have Homebrew:

brew install git

Otherwise, download the installer from git-scm.com and follow the installation wizard.

Linux: Ubuntu/Debian:

sudo apt-get update && sudo apt-get install git

Once installation is complete, let’s verify everything worked:

git --version

You should see something like git version 2.50.1 (any version 2.0 or higher is perfect).

See that? Congratulations - Git is installed! 🎉

Your Git Identity

Git needs to know who you are - not for logging in somewhere, but for accountability. Every change you make will be “signed” with your name and email, creating a clear record of who did what and when.

Let’s configure your identity:

# Tell Git your name
git config --global user.name "Your Name"

# Tell Git your email
git config --global user.email "your.email@example.com"

The --global flag means these settings apply to all Git projects on this computer.

Let’s verify your configuration:

git config --list

You should see these lines (among others):

user.name=Your Name
user.email=your.email@example.com

[!TIP] Planning to use GitHub? You can use a privacy-focused email address that GitHub provides. We’ll cover this in the next article.

Perfect! In less than 5 minutes, you’ve installed and configured Git. You’re now using the same tool that protects millions of projects worldwide.

Now for the fun part - let’s create your first Git repository and watch this time machine in action!

Creating Your First Git Repository

A Git repository (or “repo”) is just your project folder with Git’s time machine attached. Let’s make one:

# Create a new project folder
mkdir my-first-project
cd my-first-project

# Turn it into a Git repository
git init

You’ll see something like:

Initialized empty Git repository in /path/to/my-first-project/.git/

That’s it! You just created a Git repository. Git is now watching this folder, ready to track any changes you make.

Let’s create your first file:

# Create a README file
echo "# My First Git Project" > README.md

# Ask Git what it sees
git status

You’ll see:

On branch main

No commits yet

Untracked files:
  (use "git add <file>..." to include in what will be committed)
        README.md

nothing added to commit but untracked files present (use "git add" to track)

Git sees your README.md but isn’t tracking it yet - it’s waiting for you to tell it what to do. Let’s save this file to Git’s history:

# Stage the file (prepare it for saving)
git add README.md

# Save it with a descriptive message
git commit -m "Initial commit: Add README"

You’ll see:

[main (root-commit) abc1234] Initial commit: Add README
 1 file changed, 1 insertion(+)
 create mode 100644 README.md

🎉 Congratulations! You just made your first commit - your first save point in Git’s time machine. This exact version of your project is now saved forever. No matter what happens next, you can always come back to this moment.

Let’s verify your commit is saved:

git log --oneline

You’ll see:

abc1234 (HEAD -> main) Initial commit: Add README

There it is - your first checkpoint in your project’s history. Think of this like saving your game before entering a new area. From now on, every commit you make is another save point you can return to.

Ready to see how Git tracks your changes as you continue developing? Let’s explore the daily workflow that makes Git indispensable.

Tracking Changes: The Add-Commit Workflow

You’ve created your repository with one commit - think of it as your first save point in a game. Now let’s see what happens when you continue developing.

Imagine you’re about to fight a boss in a game. What do you do first? Save your progress, right? Same with code. Before making risky changes, developers create “checkpoint commits” they can return to if things go wrong.

Let’s add some features to your README and create another save point:

# Add content to your README
echo "" >> README.md
echo "## Description" >> README.md
echo "Learning Git fundamentals - one commit at a time!" >> README.md
echo "" >> README.md
echo "## Features" >> README.md
echo "- Version control" >> README.md
echo "- Time travel for code" >> README.md
echo "- Never lose work again" >> README.md

Now let’s see what Git thinks about these changes:

git status

You’ll see:

On branch main
Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
  (use "git restore <file>..." to discard changes in working directory)
        modified:   README.md

no changes added to commit (use "git add" and/or "git commit -a")

Git knows README.md has changed, but you want Git to show you exactly what changed:

git diff

You’ll see your additions in green with + signs:

 # My First Git Project
+
+## Description
+Learning Git fundamentals - one commit at a time!
+
+## Features
+- Version control
+- Time travel for code
+- Never lose work again

Happy with these changes? Let’s create a save point. But watch what happens after we stage the file:

# Stage the changes
git add README.md

# Check status again - this is important!
git status

Now you’ll see:

On branch main
Changes to be committed:
  (use "git restore --staged <file>..." to unstage)
        modified:   README.md

See the difference? Your file moved from “Changes not staged” to “Changes to be committed.”

You might be wondering: why two steps for a save point? Most of the time, you’ll do exactly what we’re doing - add and commit right away. But imagine you’ve modified 10 files and only 3 are ready. Without staging, you’d have to either:

• Commit all 10 (including half-finished work), or
• Wait until all 10 are perfect (risking the work you’ve already completed)

With staging, you can save those 3 ready files now and keep working on the others:

git add file1.js file2.js file3.js
git commit -m "Complete login feature"
# Other 7 files stay uncommitted for later

For now though, we’re keeping it simple - one file, one commit. Let’s complete the save:

git commit -m "Add project description and features list"

Now check your save points:

git log --oneline

You’ll see:

def5678 (HEAD -> main) Add project description and features list
abc1234 Initial commit: Add README

Two save points! You can now jump back to either version of your project.

The Daily Workflow

This edit → add → commit cycle becomes muscle memory:

1. Edit your files (make changes)
2. Add to staging (choose what to save)
3. Commit with a message (create the save point)

Every time you reach a good stopping point - a feature works, a bug is fixed, your code compiles - you create a commit. These aren’t just backups; they’re your safety net for fearless coding.

[!TIP] Commit when things work, not when they’re perfect. It’s better to have many small save points than one giant one. Think of it like quicksaving in a game - do it often!

Ready to keep your repository clean? Not every file belongs in Git - let’s learn what to exclude and why.

Using .gitignore: Keeping Your Repository Clean

Before we continue, let’s handle something you might notice. Run:

git status

Depending on your operating system, you might see files you didn’t create - like .DS_Store on Mac or Thumbs.db on Windows. These are system files that don’t belong in your project history.

Let’s also create a log file to simulate what happens in real projects:

echo "Debug: Application started" > debug.log
git status

Now you’ll see debug.log in your untracked files. Log files can grow huge and change constantly - they don’t belong in Git either.

Let’s tell Git to ignore these files permanently:

# Create a .gitignore file
echo ".DS_Store" > .gitignore
echo "Thumbs.db" >> .gitignore  
echo "*.log" >> .gitignore

# Check what Git sees now
git status

Magic! Git no longer shows those files. They still exist in your folder, but Git pretends they don’t exist.

Let’s save this .gitignore file:

git add .gitignore
git commit -m "Add .gitignore for system and log files"

Your repository now stays clean, tracking only what matters - your actual code. In real projects, you’ll typically ignore things like:

• System files (.DS_Store, Thumbs.db)
• Log files (*.log)
• Dependencies (node_modules/, vendor/)
• Build outputs (dist/, build/)

With your repository clean and organized, let’s explore the feature that makes Git truly powerful - the ability to recover from any mistake.

Recovering Lost Work: Git Restore and Reset

Remember those save points we’ve been creating? Time to use them. Let’s deliberately break something and watch Git save us - this is where everything we’ve learned pays off.

First, let’s admire what we’ve built. Check your README:

cat README.md

You should see your carefully crafted content:

# My First Git Project

## Description
Learning Git fundamentals - one commit at a time!

## Features
- Version control
- Time travel for code
- Never lose work again

Beautiful! Now, let’s destroy it (for science! 🧪):

echo "TODO: Write actual content later" > README.md
cat README.md

Output:

TODO: Write actual content later

Oh no! All your work is gone, replaced with a lazy TODO. This is that stomach-dropping moment from our introduction. But watch this:

git restore README.md
cat README.md

Your content is back! Every feature, every line, exactly as it was. That 2 AM panic we talked about? It just became impossible.

Going Back in Time

What if you need to go back further? Let’s see all your save points:

git log --oneline

You’ll see something like:

abc5678 (HEAD -> main) Add .gitignore for system and log files
def5678 Add project description and features list
abc1234 Initial commit: Add README

Each of these is a complete snapshot of your project. Want to go back to the very beginning?

git reset --hard abc1234  # Use your actual first commit ID
cat README.md

You’re back to:

# My First Git Project

It’s like you never made those other changes. But don’t worry - you can go forward again:

git reset --hard abc5678  # Use your latest commit ID

Everything’s back to the latest version.

[!TIP] Try this yourself: Seriously, try to break your project right now. Delete files, overwrite everything, make a mess. Then use git restore . to bring everything back. The more you break and restore, the more confident you’ll become.

This is why developers using Git code fearlessly. Every commit is insurance. Every git restore is your safety net. You can experiment, try risky changes, refactor everything - because you can always go back to when things worked.

Remember that 2 AM panic from the beginning? You just proved it never has to happen again. You have the power to undo any mistake, recover any file, and travel to any point in your project’s history.

What’s Next: Your Git Journey

Congratulations! 🎉 In less than an hour, you’ve transformed from someone who feared losing code to someone who can:

• Create and manage Git repositories
• Track changes with meaningful commits
• Ignore files that don’t belong
• Recover from any mistake instantly

You’ve kept the promise from the beginning - that 2 AM panic is now impossible. Your code is safe.

Your Next Challenge

Before moving on, solidify these skills with a real project:

1. Create a new repository for something you’re actually working on
2. Make at least 5 meaningful commits as you work
3. Deliberately break something and restore it
4. Create a .gitignore for your project type

The more you use these commands, the more natural they become. Within a week, git add and git commit will be muscle memory.

Coming Next: GitHub

You’ve mastered local Git - your code is safe on your computer. But what if your computer dies? What about collaborating with others?

In our next article, you’ll learn to:

• Push your repositories to GitHub (backup in the cloud)
• Share code with teammates or the world
• Set up your first GitHub Actions workflow
• Automate tasks that run every time you commit

We’ll take the exact repository you created today and give it superpowers in the cloud.

Ready to take your code online? Continue to Part 2: Setting Up Your First GitHub Repository: A Step-by-Step Guide →