Understanding Git: The Foundation for GitHub Actions

Introduction

It’s 2 AM. You’ve finally fixed that bug after hours of debugging - and then disaster strikes. One wrong command, and your working code is gone, replaced by yesterday’s broken version. Or maybe you’ve worked on the same project with teammates and ended up in merge conflict hell, trying to figure out whose changes to keep.

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.

Git helps you to:

• Never lose working code again - every version is saved
• Undo mistakes in seconds, not hours
• Work with teammates without fear of conflicts
• Build reliable, automated workflows later using GitHub Actions

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

• Install and configure Git on your computer
• Create your first Git repository and understand how it works
• Tracking changes to your code and commit them intentionally
• View and explore your project’s history
• Understand Git’s role in modern software workflows

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.

By the end of this article, you’ll have hands-on experience with Git’s core features, laying a strong foundation for working with GitHub and automating your workflow with GitHub Actions.

Let’s dive in and make lost code a thing of the past!

Why Git Matters: Real Problems, Real Solutions

Picture this: It’s 2 AM and you’re building a website that’s coming along beautifully. Your features are working, the code is clean, and you’re feeling confident. Then you decide to implement an exciting new navigation menu. A few hours later, not only is your new menu broken, but somehow your contact form stopped working too. Now you’re frantically trying to remember exactly what you changed, but there are too many modifications to track.

You might have tried the classic solution: creating backup copies of your project folder. We’ve all been there - folders with names like “website_final”, “website_final_v2”, and the infamous “website_final_FINAL_REALLY”. Which version had that working contact form? When did you add that specific feature? Which version is actually the latest?

There has to be a better way, right?

What is Git?

Git is an open-source version control system that tracks every change to your code, creating a complete history you can navigate, search, and restore from at any time.

But what does that actually mean for you? Let’s look at the three biggest problems that Git eliminates from your daily coding life.

Three Core Problems Git Solves

Problem 1: Lost Work You know that sinking feeling when you realize you’ve overwritten working code? When one wrong move erases hours of effort?

Git’s Solution: Every change you commit is saved forever. Made a mistake? Restore any previous version with a single command. Your code’s history becomes your safety net.

Problem 2: Risky Experiments Want to try that new feature but terrified of breaking what already works?

Git’s Solution: Branches let you create isolated copies of your project for experimentation. Think of it like having multiple drafts that don’t interfere with each other. If your experiment fails, your main code remains untouched.

Problem 3: Team Chaos When multiple developers work on the same project, whose changes win? How do you merge everyone’s work without losing code?

Git’s Solution: Git automatically merges compatible changes and clearly highlights conflicts when manual decisions are needed. No more overwriting teammates’ work or losing track of who changed what.

The Bottom Line

Without Git:

• That feature you spent 6 hours perfecting? Gone with one wrong save
• Want to try something new? Better copy your entire project first (and remember which copy is which)
• Team member made changes? Hope you enjoy manually comparing files
• “It worked yesterday!” becomes your team’s moto 😊

Ready to leave these problems behind? Let’s get Git on your computer and start transforming how you work with code.

Getting Started with Git

Now that you understand how Git solves your development challenges, let’s get it up and running on your machine.

Installing Git is straightforward - you’re essentially adding a command-line tool that will become your code’s version control system. The process takes just a few minutes, and once it’s done, you’ll have the same powerful tracking system used by millions of developers worldwide.

Installation

Let’s get Git installed on your system. The process differs slightly by operating system, but I’ll guide you through each one.

Windows:

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

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 completed, let’s verify everything worked:

git --version 

You should see something like git version 2.50.1 or newer. See that version? Perfect - Git is ready to go.

Now that Git is installed, let’s tell Git who you are.

Your Git Identity

Before we create our first repository, Git needs one piece of information: who you are. This isn’t about authentication or passwords - it’s about accountability. Every change you commit in Git carries your name and email address, creating a clear record of who did what.

This becomes invaluable when you’re looking at your code history 6 months from now, wondering “who made this change and why? 🤔” Even so more when working with a big team.

Let’s configure your identity:

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

Replace “Your Name” in the command above with your actual Name.

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

Again replace “your.email@example.com” with your actual email address.

The --global flag means these settings will apply to all your Git projects on this computer. You can verify they’re set correctly running the following command:

# View your Git configuration
git config --list 

You should see your name and email among the settings displayed. If you need to change anything, just run the configuration commands above again with your new information.

In the following sections, we’ll put Git to work by tracking an actual project.

Understanding Git Repositories

Now that Git is installed and configured, let’s dive into the core concept that makes everything possible: the Git repository.

A Git repository (or “repo” for short) is simply a project folder that Git is tracking. It contains your actual project files plus a complete history of every change ever made to them. Think of it as your project with a built-in time machine.

When you tell Git to track a project, it creates a hidden .git folder that stores all the version history - you’ll never need to touch this directly, but it’s good to know it exists.

For now we’ll focus on local repositories - ones that live on your computer. In later articles in the series, you’ll learn how the same repositories can be shared and synchronized online using platforms like GitHub, opening a world of collaboration possibilities.

Let’s create your first repository and see how this works in practice.

Creating Your First Repository

Now that you understand what a repository is, let’s create one!

Start by creating a new directory/folder for your project and tell Git to track it:

Create a new directory and navigate to it:

mkdir my-first-git-project
cd my-first-git-project

Tell Git to track it, or in other words initialize Git.

git init

That git init command just transformed your ordinary folder/directory into a fully functional Git repository!

Benind the scenes, Git creates that special .git directory we talked about earlier. From now on Git starts to track every change you make in this directory.

Now let’s make some changes to our directory, and watch how Git tracks them. We’ll start with something every good project needs - a README file.

Creating a README Markdown file

README markdown file is the first thing people see when they visit your project. For now we’ll keep it simple

echo "# My First Git Project" > README.md

This above echo command with the > symbol basically creates a new file called README.md and puts the text ”# My First Git Project” inside it.

Now let’s see what Git makes of your new repository:

git status

You should see an output like:

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 file but isn’t tracking it yet. That’s expected - Git wants you to explicitly tell it which files to track. We’ll learn howto do that in the next section.

You might notice some extra files appearing in your directory that you didn’t create - like .DS_Store on macOS or desktop.ini on Windows. These are system files that your operating system creates automatically. Git see them too, but they’re not part of your project. Let’s tell Git to ingore them.

We’ll start by creating some of those files that you might find in real-world:

# Simulates a system file (automatically created on macOS)
# `touch` command creates an empty file
touch .DS_Store

# Simulates a log file to capture some application activites
echo "Application started at 10:00AM" > debug.log

The .DS_Store file is automatically created by macOS to store folder display preferences - it has nothing to do with your code. The debug.log might be generated by your application to track what’s happening while it runs.

Check what Git sees now:

git status

You should see something like this:

On branch main

No commits yet

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

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

Git now shows three untracked files: README.md, .DS_Store, and debug.log. But tracking system files and logs would clutter your repository with unnecessary files. Log files can grow huge, and system files are specific to your computer - neither belong in your project’s history.

This is where .gitignore comes in - it’s a special file that tells Git “these files exist, but pretend you don’t see them”:

# Create a .gitignore file
echo ".DS_Store" > .gitignore    # Tell Git to ignore macOS system files
echo "*.log" >> .gitignore       # Tell Git to ignore all files ending in .log
cat .gitignore
.DS_Store
*.log

The >> symbol adds a new line to the file (while the > would replace everything). The cat command shows us the content of the .gitignore file.

Now watch what happens:

git status

You should see something like this:

On branch main

No commits yet

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

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

Magic! Git no longer mentions .DS_Store or debug.log. They’re still in your directory, but Git is ignoring them completely. You’ll only see:

• README.md (your actual project file)
• .gitignore (this special file that tells Git what to ignore)

Common things that developers include in .gitignore:

• System files (.DS_Store on Mac, The desktop.ini on Windows)
• Log files and debug output
• Dependency folders (like node_modules/ for JavaScript projects)
• Compiled code that can be regenerated
• Files with sensitive informations (Passwords or Secrets)

With your repository initialized and Git ignoring the right files, you’re ready for the next step: telling Git which files you DO want to track. Let’s explore that next.

Staging and Committing Your First Files

Git sees your files, but it’s not tracking them yet. Remember when we ran git status? Git showed us “Untracked files” - these are files Git knows exist but isn’t keeping history for. Let’s change that.

Git uses a two-step process to save files into your project’s history:

1. Stage - Select which files you want to save
2. Commit - Save those files with description

Think of it like packing boxes for moving. First, you decide what do you want to move (staging), then you seal and label the boxes for shipping (committing).

This gives you complete control over what gets saved and when.

Let’s start by staging your README.md file:

git add README.md

This command tells Git “start tracking this file and get it ready to save.” Check what happened:

git status

You should see something like this:

On branch main

No commits yet

Changes to be committed:
  (use "git rm --cached <file>..." to unstage)
        new file: README.md

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

You’ll see README.md has moved from “Untracked files” to “Changes to be committed” - it’s staged and ready to save.

Let’s also stage your .gitignore file:

git add .gitignore
git status

You should see something like this:

On branch main

No commits yet

Changes to be committed:
  (use "git rm --cached <file>..." to unstage)
        new file: .gitignore
        new file: README.md

Both files are now staged. This two-step might seem unnecessary now, but it becomes powerful when you’re working on multiple features - you can choose exactly which changes to save together.

💡 You can also add or stage ALL files at once, using git add . instead of having to add each file individually

We are now ready! let’s commit these staged files to your project’s history:

git commit -m "Initial commit: Add README.md and .gitignore"

The -m flag is short for message it lets you add a message describing what you’re saving. This message is crucial - it helps you (and others) understand what changed and why.

Good commit messages are like clear labels on those moving boxes. Check out below example of good and bad commit messages:

• ✅ “Add user login functionality”
• ✅ “Fix calculation error in shoping cart”
• ❌ “Update files” (too vague)
• ❌ “asdfasdf” (meaningless)

Your commit messages should answer: “If I apply this commit, it will…”

Let’s verify your commit worked:

git log
commit e948be1df722fb6b88e0d1d504f9d2985bda8375 (HEAD -> main)
Author: Your Name <email.address@example.com>
Date:   Fri Jul 25 13:38:37 2025 +1200

    Initial commit: Add README.md and .gitignore

You’ll see your first commit! It shows”

• A unique identifier (the commit hash)
• Your name and email (from our configuration above)
• The date and time
• Your commit message

Congratulation 🎉 You’ve just created your first Git commit. Your files are now part of your project’s permanent history. You can always come back to this exact version of your project, no matter what changes you make in the future.

Now that you understand how to save new files, let’s see what happens when you modify existing files. This is where Git really shines.

Making Changes and Tracking History

Now that you just created your restore point in Git. Let’s see Git’s real power - protecting you from mistakes.

Let’s simulate a typical development scenario. First, check what your README currently contains:

cat README.md

You should see:

# My First Git Project

Now let’s make some changes to your project description, the README file:

echo "" >> READEME.md    # Adds an empty line
echo "## Features" >> README.md
echo "- User authentication" >> README.md
echo "- Shopping cart functionality" >> README.md
echo "- Payment processing" >> README.md

Let’s check if Git has detected our changes:

git status

You will 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")

We can see that Git knows README.md has been modified! But we can go a step further to review what actually changed before committing it:

git diff

You should see:

diff --git a/README.md b/README.md
index 8299cd8..4b1c263 100644
--- a/README.md
+++ b/README.md
@@ -1 +1,6 @@
 # My First Git Project
+
+## Features
+- User authentication
+- Shopping cart functionality
+- Payment processing

Git shows your changes clearly:

• New lines appear in green with a + at the start
• Deleted lines would appear in red with a -
• You can see the exact content you’re about to commit

This two-step verification (status then diff) ensures you always know what you’re committing. Happy with the changes? Let’s stage and commit them:

git add README.md
git commit -m "Add project features to README"

Now let’s look at your project’s history:

git log --oneline

You’ll see something like:

69f89bd (HEAD -> main) Add project features to README
e948be1 Initial commit: Add README.md and .gitignore

We can see that we have two commits and two restore points in your project’s history, perfect! Ok now let’s make things interesting.

When Things Go Wrong

Let’s say you continue working and accidentally make a terrible mistake:

echo "TODO: Enhance documentation later" > README.md

Oops! We accidentally used > instead of >> which basically means we have overwritten the entire file!

Check what happened:

cat README.md

You will see:

TODO: Enhance documentation later

Oh no! All your carefully written content is gone, replaced with just “TODO: Enhance documentation later”.

In the old days, this would be panic time. But with Git? No problem:

If you know the exact file you want to revert, you can use git checkout -- filename:

git chechout -- README.md

Check your file now:

cat README.md

You will see:

#  My Firt Git Project

## Features
- User authentication
- Shopping cart functionality
- Payment processing

It’s back! Your features list is restored to the last committed version.

But what if were working on a much bigger project that our project here, and you had changed multiple files and weren’t sure which ones? You could revert everything to your last commit:

git restore .

The dot . means “all files.”

Going back Further in Time

What if, after thinking hard, you realize those features added too much complexity? You want to go back to your initial commit. You can easily do so using Git.

First, check your history:

git log --oneline

You should see:

69f89bd (HEAD -> main) Add project features to README
e948be1 Initial commit: Add README.md and .gitignore

Notice how commit messages help you understand what each commit contains? This is why good commit messages matter!

To ask Git to take us back in time to exactly how our project looked at that specific moment and forget everything that happened after that, we use git reset --hard <commit-id> :

git reset --hard e948be1

• git reset = “I want to go back in time”
• --hard = “…and I want to completely erase everything that came after”
• e948be1 = “…to this specific point in time”

Note: Replace e948be1 with your actual initial commit ID

Check your README now:

cat README.md

You’re back to just:

# My First Git Project

This is why many developers make “checkpoint commits” before starting risky changes. Think of it like saving your game before a bodd fight - if things go wrong, you can always reload from your save point.

The workflow becomes:

1. Make a commit when things are working (your checkpoint)
2. Experiment with new changes
3. If things break: restore to your checkpoint
4. If things work: make another commit (new checkpoint)

You can have as many checkpoints as you like. Each commit is a safety net, and Git always has your back.

Next Steps and Practice

You’ve learned the core concepts of Git Let’s solidify these skills with some practice exercises:

Practice Exercises:

1. Create a new project with Git init, README, and .gitignore
2. Make multiple commits with meaningful messages
3. Modify files and use git status, and git diff to review changes before committing
4. Practice reverting changes with git checkout, git restore, and git reset
5. Use git log to explore your commit history

Remeber: git status is your best friend - use it constantly to understand what Git actually sees.

What’s Next: Taking Your Code Global

Right now, your Git repository lives only on your computer. But what if your hard drive crashes? What if you want to work from another machine? What if you want to share your code with the world?

In our next article, you’ll discover GitHub - where your local Git repository can live online. You’ll learn how to:

• Create your GitHub account and first online repository
• Push your local code to GitHub with a single command
• Use VS Code’s built-in tools to make GitHub feel effortless
• Create your first pull request (the secret to collaborating with developers worldwide)

By the end of the next article, that project sitting on your computer will be accessible from anywhere in the world. You’ll join millions of developers who use GitHub to showcase their work, contribute to open source, and collaborate on amazing projects.

You’ve kept Your Promise to Yourself

Remember that 2 AM panic we talked about? The accidentally overwritten code? The fear of breaking something working?

You’ve just learned how to make those fears obsolete. Every git commit is an inssurance policy. Every git log is a detailed history. Every git restore is your safety net.

Ready to share newfound superpower with the world? See you in the next article Setting Up Your First GitHub Repository! 🚀