Getting Started With Git and Version Control: A Friendly Walkthrough For Absolute Beginners

Written by Massa Medi| May 17, 2025

Hi, I'm Kanesha, and if you don't know the first thing about Git, version control, or the basic concepts you need to be successful with Git, this is for you.

Today I'm going to teach you everything you need to get started with Git, from installation to your first commit, so you can feel confident using it on your own machine.

If you're an absolute beginner, this will help you install, configure, and understand Git and version control without getting lost in jargon or steps that assume you already know a lot.

And if you're new to the GitHub channel, go ahead and subscribe so you don't miss future uploads where we build on this foundation together.

What Is Git and Why You Need It In Real Life

Git is the most widely used version control system in the world, and that is not just a fun fact - it is the reason developers and teams can move fast without constantly breaking things.

Version control is simply a system that tracks changes to files over a period of time, which means it gives you a timeline of edits and the power to rewind or compare any point in that timeline.

To make that concrete, think about your resume for a second.

Most of us have some version of this on our laptops: resume.docx, resume_v2.docx, resume_v3.docx, and then resume_FINAL.docx that is never actually final.

Picture opening your Documents folder and seeing those four separate files - each a snapshot from a different stage of your career.

You know one has your old address, one has an updated skills section, and one includes that new internship you want to highlight.

But unless you open each one and scan line by line, you do not know which is which, and you definitely do not have an easy way to see the exact differences between them.

That is where version control steps in and makes your life easier with one main file and a complete, searchable history.

With Git tracking your resume, you keep a single file - literally one - and let Git record the changes when you save them as commits.

You get a full history where you can see who changed what, when it changed, and why it changed based on the commit message you wrote at the time.

You can jump back to a previous version without digging through copies, and you can compare versions side by side to see exactly what changed.

That same power scales from a single resume to a large app with dozens of people contributing at the same time without stepping on each other's toes.

Core Git Concepts You Must Know Before You Start

Before we type any commands, you need a mental model of how Git organizes your work.

Imagine three boxes in a row: the working directory, the staging area, and the repository.

Changes flow from left to right - edit in working, stage what you want, commit into history.

On top of that, you have branches for parallel work, remotes for collaboration, pull requests for discussion, and merging to bring it all together.

Working Directory

The working directory is your everyday workspace where you actually make changes to files.

It holds the current state of your project - maybe a new paragraph in a README, a line of code you just wrote, or a file you deleted but have not saved to history yet.

Git is watching the working directory for changes, but it does not record those changes until you stage and commit them.

Think of it like your desk - lots of ideas, sticky notes, sketches, and drafts live here until you decide what is worth filing.

Staging Area (Index)

The staging area, also called the index, is where you prepare changes for the next commit.

It is a draft space where you review exactly which changes will be saved into history together.

Maybe you edited three files but only want to commit one of them for now - staging lets you choose that one file and hold off on the others.

This control is huge for clean history and clear commit messages that actually mean something when you read them later.

Local Repository

Your local repository is the project history stored on your computer.

It includes all your commits, your branches, and the timeline of how the project evolved.

Even if you are not connected to the internet, you can commit freely and move between branches because that history is right there on your machine.

It is your personal record of the project, and it travels with the folder wherever it goes.

Remote Repository

A remote repository is a version of your project hosted on the internet or your internal network.

GitHub is a popular place to host remotes because it adds collaboration on top of Git - comments, pull requests, discussions, and permissions.

When you push, you send your commits to the remote so others can see them.

When you pull, you bring down commits from the remote that other people have added.

Branches

Branches are parallel versions of your project that share history until they diverge for new work.

You might create a feature branch to try an idea, fix a bug, or write a draft, all without touching the main branch that others depend on.

Branches make experimentation safe because your work is isolated until you decide it is ready.

When it is, you can merge it back into the main line of development.

Pull Requests

A pull request is a way to propose changes from one branch to another, usually on a platform like GitHub.

It opens a space to review, ask questions, attach screenshots, and make improvements before anything merges.

On teams, pull requests are where collaboration really happens - it is code plus conversation and context.

Even solo developers use pull requests to keep a record of decisions and to document why a change was made.

Merging

Merging integrates changes from one branch into another and combines the histories.

After review, merging creates a single unified timeline where your feature or fix becomes part of the main project.

When there are overlapping edits to the same lines, Git asks you to resolve conflicts so both histories make sense together.

Once merged, the project moves forward with the best of both branches.

Install Git On Your Machine The Easy Way

To use Git, you need it installed on your computer. macOS ships with an older version, and Windows needs a fresh install.

Either way, you want the latest version so commands behave consistently and you have the newest features.

Below are the exact steps for macOS and Windows so you can follow along without guessing.

macOS: Install With Homebrew

I am using a MacBook here. Even though macOS includes a system Git, we will install the latest version with Homebrew.

Homebrew is a package manager that makes installing developer tools straightforward.

Open your browser to the Homebrew website and copy the install command from the homepage.

Then open the Terminal app and paste the command. Press Enter and let it run - it can take a few minutes.

/bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/HEAD/install.sh)"

When Homebrew finishes, return to the Git download page or simply install Git with this command:

brew install git

When the installer completes, verify Git is available by running:

git --version

You should also see a list of commands when you run:

git

Windows: Install With the Git for Windows Installer

On Windows, head to the Git downloads page and click the Windows icon.

Click the link that says Click here to download - that gets you the most recent Git for Windows installer.

When the file finishes downloading, double-click it and follow the setup wizard prompts you see on screen.

• Click Next to accept the license terms.
• Click Next to accept the default install location.
• Click Next to keep the default components checked.
• Set the default branch name to main - this is the new convention.
• Click Next to accept the recommended PATH integration.
• Click Next to use the bundled OpenSSH program.
• Click Next through the remaining defaults and then click Install.

When the installer finishes, click Finish and open Command Prompt, PowerShell, or Git Bash.

Verify your install by running:

git --version

Then run:

git

You should see a list of available commands. If you do, you are ready for configuration.

Configure Git So Your Commits Get Proper Credit

With Git installed, the very first configuration you should set is your name and email.

Git stores this information with each commit so your work is attributed correctly in the history and on platforms like GitHub.

Open your terminal and run these commands, replacing the example name and email with your own.

git config --global user.name "Your Name"

git config --global user.email "you@example.com"

To see all current settings, you can print your config:

git config --list

That will open a pager view if there is a lot of output.

Press the Q key on your keyboard to exit the screen and return to the prompt.

Your First Git Workflow: From New Folder To First Commit

Now that Git knows who you are, let us create a tiny practice project and walk through the core commands you will use all the time.

I want you to actually type these with me - seeing the output is how it clicks.

We will make a folder, create a couple of files, initialize Git, add files, and commit our work with a message.

Along the way, we will keep using git status to see exactly what changed.

Create a New Folder and Open It

Open your terminal and create a new folder named git-practice.

mkdir git-practice

Move into the folder you just created:

cd git-practice

Open the folder in your code editor of choice so you can see files as we add them.

Create Your First File

Create a new Markdown file called hello.md:

touch hello.md

Flip to your editor and you should see hello.md appear in the file explorer.

It will be empty for now, which is fine - we will add content in a moment.

Check Status Before Initializing Git

Back in your terminal, try:

git status

If Git is not initialized yet, you will see an error that there is no Git repository here.

That is your hint to run the very first command you use in any new project.

Initialize a New Git Repository

Initialize Git in this folder so it can start tracking your work:

git init

Now check the status again:

git status

You will see your branch name (often main) and a section showing untracked files - hello.md is listed because Git sees it but is not tracking it yet.

Depending on your terminal theme, untracked files usually appear in red to signal they are not staged.

Stage Changes To The Index

Add everything in the working directory to the staging area:

git add .

Run status again:

git status

Now hello.md should be listed as changes to be committed which means it is staged.

In many themes, staged files appear in green to indicate they are ready to commit.

Edit a File, See the Difference

Open hello.md in your editor and type this line:

I am learning to use Git!

Save the file, then switch back to your terminal and check status again:

git status

You will see that hello.md has been modified in the working directory since you staged it earlier.

Stage that change too:

git add hello.md

Create a Second File To See Staged vs Unstaged

Create a new JavaScript file:

touch new-file.js

Run status again to see the contrast:

git status

You should see one file staged (hello.md) and one file unstaged (new-file.js).

The different colors and sections on the screen make it very clear what will go into your next commit.

Commit Your Work With a Clear Message

Save your staged changes to the repository history with a message:

git commit -m "Initial commit"

That command stores a snapshot of the staged files along with your message explaining what changed.

You will use this trio constantly: status to see what changed, add to stage, commit to save.

Where To Find Commands and Help

If you ever forget a command or want to see more options, run:

git

That prints a list of common commands with short descriptions.

You can also check the Git documentation website for a full list and examples whenever you want more detail.

Are Git and GitHub the Same? Quick Answer and Real Differences

This is one of the most common questions I get, and it is worth answering clearly so you know what tool you are using and why.

They are related, but they are not the same thing.

And knowing the difference actually makes you more confident when you move from your laptop to collaborating online.

Git is the version control system - the engine that tracks your file changes, commits, branches, and merges locally on your machine.

It works offline, it stores your history, and it gives you all the commands we have been running so far.

GitHub is a platform that hosts Git repositories in the cloud so you can collaborate, back up your work, and use tools like pull requests and code review.

They are designed to work together: Git runs on your computer, and GitHub is where you sync and collaborate with others.

• Use Git when you want to track your own changes, make commits, and manage branches locally.
• Use GitHub when you want to share your repo, invite teammates, open pull requests, and store your code safely in the cloud.
• Push and pull connect the two - push sends your local commits to GitHub, pull brings down updates from GitHub to your machine.

When To Use Which Command: A Beginner's Mental Checklist

As you practice, your brain will build a rhythm for Git, but a quick mental checklist helps a lot at the start.

Think of it as a small loop you repeat while you work so your history stays clean and you never lose changes.

Your Everyday Loop

• Edit files in the working directory.
• Run git status to see what changed.
• Stage what belongs together with git add <file> or git add ..
• Commit with a clear message using git commit -m "message".
• Repeat as you make progress.

When You Want To Experiment

• Create a branch with git switch -c feature-name or git checkout -b feature-name.
• Do your work and commit in small chunks.
• Open a pull request on GitHub when you are ready for review.
• Merge the branch back into main when it is approved and tested.

Notice how everything builds on the basics you learned above - status, add, commit, and then branching when you need a separate lane.

Keep it simple at first and you will pick up speed fast.

Common Visual Cues You Will See In Your Terminal

Since you cannot see my terminal right now, let me paint a quick picture so you can recognize what each state looks like on your screen.

Different terminals and themes vary a bit, but the patterns are similar everywhere.

• Untracked files usually appear in red under a section labeled Untracked files. Git sees them but is not tracking them yet.
• Changes to be committed is the section for staged files, often shown in green, which will be included in your next commit.
• Changes not staged for commit lists files you have modified but not staged yet - this is your cue to run git add.
• The branch line near the top shows which branch you are on - main at the start, or a feature branch when you create one.

Over time, just glancing at git status tells you the full story of where your work stands right now.

That quick feedback loop is what makes Git feel like a trusted helper instead of a hurdle.

Wrap Up: You Installed Git, You Configured It, You Committed - You Are On Your Way

Let us zoom out for a second and look at what you just accomplished.

You learned what Git and version control are with a real-world example, not theory you will forget in five minutes.

You installed Git on macOS or Windows, configured your name and email, and ran the core commands that you will use every single day.

You created a folder, initialized a repo, staged changes with intention, and wrote your first commit message like a pro.

From here, the next steps flow naturally: create a GitHub account if you do not have one, make a new repo, and practice pushing your local commits to the cloud.

Open a pull request from a feature branch into main to see that review workflow in action, even if it is just you leaving notes for future you.

And keep that simple loop close: edit, status, add, commit. It is the heartbeat of every Git project, big or small.

Thanks for learning with me. If this helped, like and subscribe on the GitHub channel so you do not miss future videos where we build on this foundation. Happy coding.

Entities covered: Git, Version Control, GitHub, Homebrew, macOS, Windows, OpenSSH, Terminal, Command Prompt, Git Bash.

Who this helps: Beginners setting up Git for the first time - students, new developers, career switchers, and anyone who wants a safe way to track files.

Why it matters: Version control protects your work, speeds up collaboration, and gives you a clean history to learn from and share.

Where it applies: Globally - the same commands and concepts work no matter where you are or what project you are building.