Git for Beginners: Basics and Essential Commands

Introduction

The objective of this blog is straightforward: to help a beginner understand how Git is structured at local and remote level, how its workflow operates, and how to use the minimum viable set of Git commands with confidence.

At its core, Git is a distributed version control system that helps developers track changes in their code, maintain a reliable history of those changes, and collaborate without overwriting each other’s work. It is used because modern software development demands safety, traceability, and coordination—especially when multiple people are working on the same codebase.

This article is a continuation, not a restart. In the previous blog, I discussed what collaboration looked like before version control systems, the infamous pendrive problem, the emergence of version control and remote servers, the limitations of earlier systems, and finally, the birth of Git as a solution to those challenges. If you’re curious about Git’s origin story, you can read it here; otherwise, you can continue directly.

With that foundation already in place, this blog shifts focus from why Git exists to how Git is actually used. The emphasis is purely practical: understanding the core terminologies that are required to understand the Git workflow, how changes move through Git’s workflow, understanding how the commits are connected and their flow, and how a small but essential set of commands supports clean, repeatable, and collaborative development.

The goal is clarity, not complexity. By the end of this guide, you should be able to read a Git command, understand its role in the workflow, and use it deliberately rather than mechanically.

---

Core Git Terminologies

Before learning Git commands, you need to understand a few basic words. These terms explain how Git thinks about your code. Once these are clear, Git starts to feel logical instead of confusing.

Let’s go through only the essentials.

1. Repository (Repo)

A repository (or "repo") is a storage location that contains all of your project files, along with the complete history of changes, branches, and metadata. It serves as the central hub for tracking, managing, and collaborating on a project using the version control system.
A local Git repository is essentially the hidden .git directory within your project's main folder. Deleting this directory removes your project's entire history. We will discuss about it in detail in next blog.

Think of it like a project box. Inside this box, Git keeps your code and also remembers every change you make over time.

• Your project lives here
• Git history lives here
• Commands work inside this repo

2. Working Directory

A working directory, or Current Working Directory (CWD), is your current location within a computer's file system where you actually write code.

It is the folder you see on your computer where you:

• create files
• edit files
• delete files

Think of it like your notebook on the desk where you are actively writing.

3. Unstaged Area (Including Untracked Files)

In VCS, the "unstaged area" refers to the live folder on your computer where you make file changes (add, edit, delete)—containing modifications that Git is aware of (modified/deleted) but hasn't yet prepared for a commit, or brand new files (untracked) that Git isn't tracking at all.

This includes:

• modified files (changed but not staged)
• untracked files (new files Git has never seen before)

Think of this area as rough work:

• ideas that are not ready to be saved
• files that are still being worked on

Until you stage them, Git will not prepare them for a commit.

4. Staging Area

In VCS, the staging area is an intermediate space between your working directory (where you edit files) and the local repository (where commits are stored) that lets you carefully craft your next commit. The staging area is where you select changes that are ready to be saved.

Think of it like a tray where you place only the finished pages.

This allows you to:

• choose specific files to save
• avoid committing incomplete work

Only staged changes move forward to a commit.

5. Commit

A commit in version control is an operation that permanently records changes to the codebase as a single unit, essentially acting as a saved checkpoint or snapshot of the project's files at a specific moment in time. Each commit is a node in the project's history, allowing developers to track progress, understand the project's evolution, and revert to previous states if necessary.

Think of it like pressing Save in a game.

• Git takes a snapshot of staged changes
• you add a short message describing what you did

Each commit becomes part of the project’s history.

6. Branch

In version control, a branch is an isolated copy of your codebase (or a specific file) that allows developers to work independently on new features, experiments, or bug fixes without affecting the main, stable code (often called main or master). It's like creating a separate development line, enabling parallel work, testing, and then merging changes back when ready, ensuring the core project remains stable and organized.

Think of it as making a copy of your notebook to try something new.

• experiments stay safe
• the main work stays stable

Branches help you work without fear.

7. HEAD

In version control systems like Git, HEAD is a symbolic reference (a pointer) to the currently checked-out commit. Whenever there is a new commit, HEAD shifts from the previous commit and points to the latest commit.

It points to:

• the current branch
• the latest commit you are working on

Think of HEAD as a bookmark. We are going to discuss it in detail in our next blog, which will be on the internal structure and working of the .git directory.

8. Remote

In version control systems like Git, a remote (short for remote repository) is a version of your project that is hosted on a server, usually on the internet or a private network.

Think of it as a cloud backup that others can access. This is how teams share code.

Final Mental Model

You can think of Git like this:

• Working Directory → where you write
• Unstaged Area → unfinished work
• Staging Area → ready work
• Commit → saved checkpoint
• Remote → shared backup

If this flow makes sense, Git will feel much easier when you start using commands.

---

Essential Git Commands

Git has many commands, but beginners do not need all of them at once.
In this section, we’ll focus only on the minimum set of commands that help you work comfortably with Git in real projects.

But before using Git commands, you need to check whether Git is installed on your system and know who you are. This setup is required only once.

---

🔹Git Setup Commands

• To check if Git is installed or not, or to check the version, open your terminal and run:

git --version

If Git is installed correctly, you will see a version number like this:

This is like opening an app to check if it launches properly.

• Tell Git Who You Are. Git saves every change along with the name and email of the person who made it. Git needs to know your identity.

Set your name:

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

Set your email:

git config --global user.email "[e-mail]"

Think of this like writing your name on the first page of a notebook. Every saved change will now have your signature.

You can check it using the command:

git config --list

---

🔹 Repository Setup Commands

These are the commands required before starting any project.

1. git init:

git init creates a local Git repository in your project. It simply associates Git with your working directory, so it can start tracking files in this folder as instructed.

Think of this like opening a new notebook and telling yourself:
“From now on, I will keep a history of everything I write here.”

When to use it

• When you start a brand-new project
• When you want to track an existing folder with Git Example

---

2. git clone

git clone copies an existing repository from a remote source to your computer. Allowing you to work on it locally.

git clone <repository-url>

Think of it like downloading a shared Google Drive folder to your laptop so you can work offline.

When to use it

• When a project already exists online
• When you want your own local copy to experiment

---

🔹 Daily Workflow Commands

These are the commands you’ll use every day.

3. git status

git status shows the current state of your project.

It tells you:

• which files are changed/modified
• which files are staged
• which files are untracked

Think of it as checking your to-do list before doing anything else.

When to use it

• Before adding files
• Before committing
• Whenever you feel confused

---

4. git add

git add moves changes from the unstaged area to the staging area. After any modifications in older files or after creating a new file, we need to add those files to shift them to the staging area. This command selects the files you want to save and prepares them for commit.

Think of this like selecting pages you want to photocopy before pressing print.

When to use it

• After modifying files
• Before making a commit

This is used to add a particular file to the staging area.

git add <filename>

This is used to add all changes to the staging area.

git add .

---

5. git commit

git commit saves the staged changes as a permanent checkpoint. Each commit includes a message explaining what changed. It basically creates a snapshot of your project & stores it in Git history with a message.

Think of it like saving a game with a note, such as “Level 3 completed”.

When to use it

• After finishing a small, meaningful change Example

git commit -m "msg"

⭐ There is a shortcut that lets you save all your staged and modified tracked files with a message — in one go, which is git commit -am "msg" .

⚠️ REMEMBER!
It does NOT include new files (untracked files). You must run git add first for those.

---

6. git log

git log shows the history of commits.

You can see:

• the commit message
• when it was changed
• who changed it
• the commit id

Think of it as flipping through old diary entries of your project.

When to use it

• To review past work
• To understand project history

To see who changed and when with the commit message in detail.

git log

To see the commit messages with the id only (in short)

git log --oneline

---

7. git diff

This command shows the difference between versions of files. By default, it compares: working directory vs staging area.

But by using commit IDs, we can compare different commits also.

Think of it as:

• Comparing a rough draft with the edited version.

• Comparing 2 different versions of the same book.

When to use

• Before staging or committing
• Whenever you feel confused

To compare between Working directory and the Staging area

git diff

To compare different commits

git diff <old commit-id> <new commit-id>

---

8. git revert

Creates a new commit that undoes a previous commit. It doesn't delete the previous commit from the history.

It's like crossing out a mistake but keeping the record.

When to use

• To undo changes safely in shared projects

git revert <commit-id>

---

9. git reset

This command is used to undo changes in your working directory and staging area. Basically, it is like a time machine in Git — it lets you go back to an earlier point in your project. But depending on how you use it, it can either just move a bookmark or also erase your work.

Just like erasing pencil marks before anyone else sees them.

When to use

• Locally
• Whenever there's any issue with the code
• Before pushing changes

git reset <commit-id>

This command has three main modes: --soft, --mixed, and --hard. Each mode affects the working directory and staging area differently.

• --soft The --soft option moves the HEAD pointer to the specified commit but leaves the working directory and staging area unchanged. This means that all changes from the reset commit will be staged for the next commit.

git reset --soft <commit-id>

• --mixed The --mixed option (default) moves the HEAD pointer to the specified commit and resets the staging area to match the specified commit, but leaves the working directory unchanged. This means that all changes from the reset commit will be unstaged but still present in the working directory.

git reset --mixed <commit-id>

• --hard The --hard option moves the HEAD pointer to the specified commit and resets both the staging area and the working directory to match the specified commit. This means that all changes from the reset commit will be lost.

git reset --hard <commit-id>

⚠️ Use carefully. This rewrites history.
git revert is safer than git reset because it adds a new commit to undo changes, while git reset erases history — which can break things for others if you're working in a team.

---

🔹 Branching Commands

Commands that are required to work with branches.

10. git branch

The git branch command is used to manage branches in a Git repository. Branches are essential for parallel development, allowing multiple developers to work on different features or fixes simultaneously without interfering with each other's work.

Think of it like creating a new notebook for a different idea. Or to create the list of notebooks.

When to use

• Starting a new feature
• Listing the features of project

To list all branches in your repository, use the git branch command without any arguments. This command will display all branches, with the current branch highlighted with an asterisk (*).

git branch

To create a new branch, you can use the git branch command followed by the name of the branch you want to create. This command just creates a new branch but doesn't switch automatically. For example:

git branch <feature-branch>

To delete a branch, use the -d option with the git branch command.

git branch -d <old-feature>

To rename a branch, use the -m option with the git branch command:

git branch -m <old-name> <new-name>

---

11. git checkout

To move between different branches or to create and switch to a new branch, we use this command.

Think of it like switching between different notebooks or creating a new notebook for a different subject and switching to it from the previous one.

When to use

• To work on a different branch

To create and switch to the new branch simultaneously, you can use the -b option with the git checkout command:

git checkout -b <new-feature>

To switch to an existing branch, use the git checkout command followed by the branch name:

git checkout existing-feature

---

🔹 Remote Repository Commands

These are the commands that are required to work with remote repositories.

12. git remote

The git remote command is used to manage the set of repositories (remotes) whose branches you track.

When to use

• To verify remote setup

To display the URLs of the remotes, use the -v or --verbose option:

git remote -v

To add a new remote i.e, to connect the local repository with the remote repository, use the add subcommand followed by the name and URL of the remote repository:

git remote add <name> <URL>

For example:

git remote add origin https://github.com/user/repo.git

Origin is just the default name Git gives to the main remote repository.

---

13. git push

The git push command is used to upload local repository content to a remote repository. The command updates the remote branch with local commits, making your changes accessible to others whom you may be collaborating.

It's like uploading saved work to the cloud.

When to use

• After committing locally The basic syntax of the git push command is:

git push <REMOTE-NAME> <BRANCH-NAME>

For example, to push your local changes to the main branch of the remote repository named origin, you would use:

git push origin main

---

14. git pull

git pull is a command that updates your local branch with the latest changes from a remote repository. It combines two steps: git fetch (download changes) and git merge (apply them to your branch).

Imagine you're working on a group project with a shared notebook:

• Your teammate adds new pages to the notebook (remote changes).

• You want to see and use those new pages in your own copy.
  Running git pull is like:

• First, getting the new pages from your teammate (fetch).

• Then, attaching them to your own notebook (merge).

When to use

• Before starting work

git pull origin main

---

Git Workflow

Let's understand the Git workflow diagram with some Git commands.

---

How Commit History Flows

In Git workflow, every commit points to the previous commit. A HEAD pointer is there which always points to the current commit of the current branch. Whenever there is a new commit added, the HEAD pointer shifts from the previous one and points to the current latest commit. Here are the two diagrams that will help you to understand the commit history flow.

---

A Simple First-Time Git Routine (From Scratch)

When you are working on a project for the very first time, this is the basic Git flow you follow.

1. git init
2. git branch -M main
3. git remote add origin <repository-url>
4. Write or modify code
5. git status
6. git diff
7. git add
8. git commit
9. git push -u origin main

How to think about it:

• First, tell Git to track the project (git init)
• Set the main branch (git branch -M main) (forceful renaming of the master branch to main branch).
• Connect your project to a remote repository (git remote add origin <url>)
• Write code
• Review and save your work (status , diff , add , commit)
• Upload it to the remote for the first time (git push -u origin main) After this initial setup, your daily routine becomes much simpler.

After the First Push (Daily Routine)

git pull
→ write code
→ git add
→ git commit
→ git push

---

Conclusion

Git may look intimidating at first, but at its core, it is simply a system for tracking change with discipline. Once you understand how the working directory, staging area, local repository, and remote repository fit together, Git stops being mysterious and starts becoming predictable.

In this guide, we focused on what matters most for beginners: the Git workflow, essential commands, and how real developers use Git from scratch. If you can follow the workflow, read the diagrams, and explain why each command is used, you already have a solid foundation to work confidently on real projects.

In the next blog, I’ll go one level deeper and explore the internal working of the .git directory—what’s inside it, how Git actually stores data, and how commands interact with Git’s internal structure. If you’re curious about how Git works behind the scenes, make sure to follow my account so you don’t miss it.

Until then, practice the workflow, break things safely, and let Git work for you, not against you.

---

Follow for more beginner-friendly breakdowns of core software engineering concepts.