Skip to main content

Command Palette

Search for a command to run...

Git for Beginners: Basics and Essential Commands

Updated
7 min read

What is Git?

Imagine you’re writing a school assignment on your computer.

You save it as:

assignment.doc

Then you make changes.

Now you're scared to lose the original version, so you save it as:

assignment_final.doc

Then again:

assignment_final_v2.doc
assignment_final_v2_latest.doc
assignment_final_really_final.doc

Sound familiar? 😄

Now imagine doing this — not alone — but with 5 other people.
That’s when things become messy.
This exact problem is what developers faced before Git.

So… What Is Git?

Git is simply a smarter way to save your work.

Instead of creating “final_v2” files, Git keeps track of every change you make — automatically and neatly.

It remembers:

  • What you changed

  • When you changed it

  • Why you changed it

  • Who changed it

In technical terms:

Git is a distributed version control system. Version control means managing different versions of your files over time. Instead of overwriting your old work, you create a history of changes. What Does “Distributed” Mean? Older systems required a central server. Git works differently.

With Git:
Every developer has a full copy of the project, including its entire history, on their own computer.

This means:

  • You can work offline

  • You have backup of full history

  • You are not dependent on one central machine

That’s why Git became so popular.

Why Git is Used?

Developers use Git because it solves real problems:

  • It prevents accidental overwriting

  • It keeps a complete history of changes

  • It allows multiple developers to work at the same time

  • It helps teams experiment safely using branches

  • It allows going back to older versions instantly

Git doesn’t just store files. It stores snapshots of your project over time. Git works in three main steps.

Imagine this flow:

You write code → You prepare what to save → You permanently record it.

Technically, these three areas are:

  1. Working Directory: Where you edit your files.

  2. Staging Area: Where you select which changes to save.

  3. Repository: Where Git stores permanent snapshots called commits.

Git Basics and Core Terminologies

Before using Git confidently, it helps to understand a few important words you’ll hear again and again.

Let’s start with something simple: the repository.

A repository (often called a “repo”) is just your project folder, but with Git watching it. When you run git init inside a folder, Git starts tracking everything inside it. From that moment on, every change you make can be recorded. So instead of being just a normal folder, it becomes a tracked project with memory.

Now comes one of the most important concepts in Git: the commit.

A commit is like taking a snapshot of your project at a specific point in time. Imagine finishing a small task maybe you added a login form or fixed a bug. When you commit, Git saves the current state of your files. But it doesn’t just save the files silently. It also records who made the change, when it was made, and a short message explaining what was done. Over time, these commits create a timeline of your project’s evolution.

Next is branching, and this is where Git becomes really powerful.

A branch is simply a separate path of development. Let’s say your main project is working perfectly, but you want to experiment with a new feature. Instead of risking the stable version, you create a branch. On that branch, you can freely test, modify, and build. If everything works well, you merge those changes back into the main project. If it doesn’t work, you can simply delete the branch , no damage done. It’s like creating a safe playground for new ideas.

Finally, there’s something called HEAD.

HEAD might sound technical, but the idea is simple. It just tells Git where you currently are in your project’s history. Think of your commits as a timeline. HEAD is like a marker pointing to the commit you’re currently working on. Whenever you switch branches or move between commits, HEAD moves with you.

Understanding these terms makes Git feel much less intimidating. They’re not complicated concepts — they’re just structured ways of managing your work safely and clearly.

Common Git Commands

Now that you understand the basic concepts, let’s talk about the commands you’ll actually use. Don’t worry, you don’t need to memorize dozens of them. In the beginning, a small handful is more than enough to work comfortably with Git.

git init

Everything usually starts with git init. This is the command that turns a normal project folder into a Git repository. The moment you run it, Git begins tracking changes inside that folder. It’s like telling Git, “Hey, start watching this project.”

git status

Once Git is tracking your project, you’ll often use git status. This is one of the most helpful commands for beginners. It shows what has changed, which files are modified, and what is ready to be committed. Think of it as a quick health check for your project.

git add

When you modify files and want to include them in your next snapshot, you use git add. This command prepares your changes for committing. It doesn’t save them permanently, yet it just tells Git, “Include these changes in the next commit.” You can add specific files or add everything at once.

git commit

After that comes git commit. This is where your changes are officially saved into Git’s history. When committing, you also write a short message explaining what you did. Good commit messages make it much easier to understand your project later.

git log

Another very useful command is git log. This command shows the history of your commits. Every time you commit, Git saves it in a timeline. When you run git log, you can see a list of all those commits along with the author name, date, and commit message.

This becomes especially helpful when your project grows. Instead of guessing what changed and when, you can simply check the log and track the exact history of your work. It’s like scrolling through the memory of your project.

If you want a shorter and cleaner view, you can use git log --oneline, which shows each commit in a compact format.

git branch and git checkout

As your project grows, you’ll start working with branches. To create a new branch, you use git branch, and to switch between branches, you use git checkout (or git switch in newer versions of Git ). This allows you to move between different lines of development without affecting your main work.

git merge

When your new feature is ready, you can combine it back into your main branch using git merge. This brings the changes from one branch into another, usually back into your main project.

git push and git pull

And finally, if you’re working with remote repositories like GitHub, you’ll use git push to upload your commits and git pull to download the latest changes from the remote server. These commands help you collaborate with others and keep everything synchronized.

At first, these commands might feel unfamiliar. But after using them a few times, they start to feel natural. Git isn’t about memorizing commands — it’s about understanding the workflow.

A Simple Git Workflow from Scratch

Let’s imagine you are starting a new project from zero.

First, you create a new folder for your project and open it in your terminal. To start using Git, you run:

git init

Now Git is tracking your project.

Next, you create a file for ex: index.html and add some basic code inside it. After saving the file, you can check what changed using:

git status

Git will tell you that a new file has been added but is not yet tracked.

To prepare it for saving, you run:

git add index.html

Now the file is in the staging area. It’s ready to be committed.

Then you save this snapshot using:

git commit -m "Add initial index file"

That’s it — your first commit is done.

If you run:

git log

You’ll see your commit in the project history.

From here, every time you make changes, you repeat this simple flow:

Modify → Add → Commit

And that’s the core Git workflow most developers follow daily.

More from this blog

Yashika’s Dev Journey

26 posts

Documenting my journey from frontend to full stack development.

I write about JavaScript, backend concepts, and real-world development problems — focusing on understanding how things actually work rather than just using them.

Building in public, learning deeply, and sharing everything along the way.