Git for Beginners : What/Why/How of it

If you're a beginner, relax (Me too. Same pinch).

If Git feels confusing, that's normal (Me too. Same pinch).

Have you ever feared learning Git (Haha.. third time is the charm they say. Me too. Same pinch).

So in the last article we talked about Version Control and it’s requirement. So, naturally the next question that jumps out is “how do we achieve this version control?” and is there any software which is there which helps in doing that. Well, I am glad to introduce you to GIT. There are many more out there which does the same job what GIT does like Mercurial , SVN, CVS and many more. But today we would be talking and learning about the most famous of them all. Now, don’t confuse it with Github. We’ll come to that also, but not in this article.

So, after looking at uncountable video tutorials on YouTube, some very very good ( i’ll try and provide links at the last), some total waste of time, here i am, ready with my notes and new gyan i gained over the last ten odd days, here i am… Again…. With the aim to help anyone who’s in the same state that i was ten days back…. Hopefully!!!

So….. let the gyan ganga flow……

---

What is Git?

Git is a Distributed Version Control System (last article).

If you haven’t gone through my last article the sentence above may sounds intimidating, so let's translate it into human language. Git is:

• A system that tracks changes in your code so you can see what changed and when.

• It’s a tool or you can say, a software that lets you go back in time using saved "snapshots" called commits (Remember “Undo” in Microsoft Word !!!! Somewhat similar but way more powerful).

• A way for multiple developers to work together without chaos on the same project (The Three Friends Pen Drive Project….. Again for the last time…. last article. please just go and read it. It’s just 5 mins).

"Distributed" simply means:

• Every developer has a full copy of the project and its entire history on their own laptop.

• You don't need pen drives, zip files, or email attachments just to share code.

Moving on to the next obvious question……

---

Why Do We Need It?

Git was created because software development outgrew human memory. As projects grew, mistakes increased, and "who changed what?" became a daily nightmare.

And Git came as a solution which solved these three massive problems:

1. The Fear of Breaking Code

• With Git, you can try things.

• If it fails, you roll back to the last "save point." Just like the “Undo” button.

• Confidence replaces fear because you always have a safe version to return to (Kaash kuch aisa zindagi ke liye bhi hota).

2. Collaboration Without Confusion

• Multiple people can work on the same project at the same time, even on the same file.

• Instead of overwriting each other's changes, Git helps you merge the work safely into a main branch (often called main or master (as it was called in earlier versions)).

3. Accountability

Git remembers:

• What changed

• Who changed it

• When it changed

• Why it changed (your commit message)

This audit trail is gold when debugging or reviewing code ( aisa tutorials main bola tha. I don’t know it yet as i am yet to start coding).

So let’s start the journey of GIT now…..

---

Getting Set Up : Installation & Tools

Before we start typing commands, first let's get Git installed on our machines. You can follow the steps below for the same.

1. Where to Download from :

Go to the official website: https://git-scm.com/downloads

• Windows:
  Download the Windows installer.
  During installation, you can safely click "Next" through most options.

• Mac:
  You can download the installer from the site, or, if you use Homebrew:

    brew install git
  

• Linux:
  You probably already have it ( again tutorial gyan) .
  If not, for Debian/Ubuntu-based systems:

    sudo apt-get install git
  

2. Next Step : Verification

Once installed, open your terminal (Command Prompt on Windows, Terminal on Mac, or Git Bash) and type:

git --version

If it replies with something like:

git version 2.43.0

you're ready. But before we move ahead and start to learn the basic commands of git, we have to talk a little bit about the fear of “Black Screen” or the command prompt.

---

The "Black Screen" Fear : CLI vs GUI

For many beginners ( like me), the scariest part of Git isn't Git itself - it's the Command Line Interface (CLI).
That black screen with white text looks like something from the Matrix or the Hacker movies, and it feels scary.

And the most obvious question which comes to the mind of beginners is this :

"Can't I just use a button?" (GUI Clients)

Yes, you can! There are Graphical User Interfaces (GUIs) that make Git look like a normal app with buttons for "Commit" and "Push." and some popular options available are:
(ChatGPT Gyan)

• GitHub Desktop – Very beginner-friendly and visual.

• VS Code – Has a built-in "Source Control" tab (the branching icon) that is excellent for everyday work.

• Sourcetree – Great for visualizing complex history and branches.

BUT BUT BUT ….You Should Learn the Command Line Anyway

If GUIs exist, why do so many tutorials (including this one) push you toward the command line? This was my question too. But in simple language:

• It is universal : The commands are almost the same on Windows, Mac, and Linux. Learn once, use anywhere.

• You see what's actually happening : GUIs hide the magic. One click might run three separate Git commands. If something breaks, you won't know which part failed.

• Troubleshooting: When you search an error, most answers on the internet show commands, not GUI buttons.

My advice:

Start with the command line to understand the basics: init, status, add, commit, log, and later push/pull.
Once you're comfortable, feel free to use a GUI (like VS Code) for day‑to‑day work.

Now, that we have understood all of this ( i hope!) and installed GIT on our machine lets move ahead.

---

The Mental Model : How Git Thinks

Before we type commands, we need to understand the Three Zones of Git.
This is where most beginners get stuck, but it's actually simple.

1. Working Directory
   The folder where you are currently writing code. These are your real files on disk.

2. Staging Area (also called the index)
   A "waiting room" where you pick which changes you want to include in the next save.
   You move changes here using git add (more on this later).

3. Repository
   The permanent history where your snapshots (commits) live, stored inside a hidden .git (next article may be) folder.

Flow in practice:

Edit files  →  git add  →  git commit
Working dir   Staging       Repository

Key Terminologies in GIT (Translated in Human Language)

Again, before we move ahead, Let's decode a few key terms that Git throws around which seems intimidating :

• Repository (Repo)
  A folder that Git is watching closely.
  Once a folder becomes a repo, Git starts storing its history inside a .git directory.

• Commit
  A saved snapshot of your project at a given point in time.
  Think of it as a "Save Point" in a video game, with a message describing what you did.

• Branch
  A parallel universe for your code.
  You can create a branch to test a crazy idea.
  If it works, you merge it into your main branch.
  If it fails, you delete the branch and your main code is untouched.
  (If you don’t understand this now, read ahead, and i guarantee that you would)

• HEAD
  A pointer that says "You are here."
  It usually points to the latest commit on the branch you're currently on.

• Main branch (main/master)
  The primary, "official" line of development in most projects.

• Remote
  A version of your repository hosted elsewhere (like GitHub, GitLab, or Bitbucket) so you can share and sync your work.
  (More on this sometime somewhere else…)

---

Essential Commands (No Magic, Just Steps)

Now, coming on the meat of this article. “THE COMMANDS - AND WHAT DO THEY DO”

Open your terminal. Here are the only commands you need to start.

1. git init

This is the first command which you have to use once per project,in your main project folder and it turns a normal folder into a Git repository.

git init

Noob Translation : "Git, wake up and start watching this folder."

This creates a hidden .git directory where Git stores all its history and metadata.

---

2. git status

This is the most important command. And i would suggest to run this constantly.

git status

Noob Translation : "Git, what is going on? Did I change anything? What's staged? What's not?"

It tells you:

• Which branch you're on

• Which files are untracked

• Which changes are staged or not staged

---

3. git add

This command moves your changes ( or when using for the first time, the files and folders that you want to add in the .git folder for tracking) that were made in your code files from your Working Directory to the Staging Area (the waiting room).

git add index.html
# OR to add everything at once:
git add .

Noob Translation : "I want to include these changes in my next save."

Note: You control exactly what goes into a commit by choosing which files (or even which lines) to add.

---

4. git commit

This is the command which actually saves the snapshot to history. Always write a message to remember what you are changing so that it is easier for you to track the changes that you are about to make to the code base of the project.

git commit -m "Added a login button"

Noob Translation : "Save the game now. Label this save 'Added a login button'."

Each commit:

• Gets a unique ID (a hash)

• Stores your message, author, date, and all staged changes

You'll later see these commits when you run git log.

---

5. git log

Shows the history of all your commits.

git log

commit ca82a6dff817ec66f44342007202690a93763949 (HEAD -> main, origin/main)
Author: Sarah Jenkins <sarah.jenkins@example.com>
Date:   Sun Jan 18 14:30:00 2026 -0500

    Fix bug in user authentication flow

commit 8a2b3c4d5e6f7g8h9i0j1k2l3m4n5o6p7q8r9s0t
Author: David Lee <david.lee@example.com>
Date:   Sat Jan 17 09:15:22 2026 -0500

    Add responsive design to landing page

commit 1234567890abcdef1234567890abcdef12345678
Author: Sarah Jenkins <sarah.jenkins@example.com>
Date:   Fri Jan 16 16:45:00 2026 -0500

    Initial commit

Noob Translation : "Show me the timeline of everything I've ever done."

It displays:

• Commit IDs

• Author

• Date

• Messages

What you see here in the code block above is:

• Commit Hash (ID): The long alphanumeric string (SHA-1 checksum) that identifies the commit.

• Refs: (HEAD -> main, origin/main) shows where your current checkout is and where the remote branch is.

• Author & Date: Who made the change and when.

• Message: The description of the change.

You can press q to exit the log view.

---

Inspecting & Undoing Changes

Once you start committing regularly, you'll need ways to see exactly what changed - and sometimes undo mistakes. Here are three essential commands for that.

6. git diff

This command shows the exact line-by-line differences between file versions and see unstaged changes (working directory/file vs staging area):

git diff

Noob Translation : "Show me what I've changed but haven't staged yet."

Example output:

diff --git a/index.html b/index.html
index 83a3f01..f9c2d8e 100644
--- a/index.html
+++ b/index.html
@@ -5,6 +5,7 @@
   <title>My App</title>
 </head>
 <body>
+  <button>Login</button>
   <h1>Welcome</h1>
 </body>

Lines starting with + are additions and lines starting with - are deletions.

See staged changes (staging area vs last commit):

git diff --staged

Noob Translation : "Show me what's about to be committed."

Compare two commits:

git diff abc1234 def5678

Replace abc1234 and def5678 with actual commit hashes (you can find them with the git log command).

Compare a specific file:

git diff index.html

Tip : Use git diff before committing to review your changes one last time.

---

7. git reset

This command moves commits or staged files backward ie it is used to "unstage" or "undo" commits locally.

Unstaging a file (keeps changes in working directory):

git reset index.html

Noob Translation : "I changed my mind so remove index.html from the staging area, but don't delete my edits."

Unstage everything:

git reset

Undo the last commit but keep changes staged:

git reset --soft HEAD~1

Noob Translation: "Undo my last commit, but leave all those changes in the staging area so I can recommit differently."

Undo the last commit and unstage changes (default behavior):

git reset HEAD~1
# or equivalently:
git reset --mixed HEAD~1

Noob Translation : "Undo my last commit and move changes back to the working directory (unstaged)."

Completely discard the last commit and all changes (very very dangerous… DO IT ONLY ONCE YOU UNDERSTAND IT PROPERLY):

git reset --hard HEAD~1

Noob Translation : "Nuke the last commit. Pretend it never happened. Delete those changes from my files too."

Just a friendly warning again : --hard permanently deletes uncommitted work. Use with caution.

Quick reference table:

---

8. git revert

This command creates a new commit that undoes a previous commit and is safest for shared/public history.

git revert abc1234

Noob Translation : "Make a new commit that reverses whatever abc1234 did."

Example :

Your commit history looks like this:

A --- B --- C --- D  (main, HEAD)

Commit C introduced a bug. You want to undo C but keep D.

git revert <hash-of-C>

Git creates a new commit E that reverses C:

A --- B --- C --- D --- E  (main, HEAD)
                        ↑
                   "Revert C"

Your history is preserved (nothing is erased), and the bug is gone ie whatever cahnges you did in C are reverted back to B and it also keeps whatever changes you did in E.

Revert the most recent commit:

git revert HEAD

Revert without auto-committing (if you want to edit first):

git revert --no-commit abc1234

This applies the reverse changes to your working directory so you can review or modify before committing.

git reset vs git revert : When to Use Which?

Rule of thumb (as i’ve understood) : If others have seen the commit, use revert. If it's only on your machine, reset is fine (only if you understand what you are doing).

---

A Real Developer Workflow (From Scratch)

Here's how a normal developer actually uses Git, step‑by‑step, on a brand‑new project.

1. Create a project folder

    mkdir my-app
    cd my-app
   

2. Initialize Git

    git init
   

3. Configure your identity and tell git about yourself(usually done once globally)

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

4. Write some code

   Create index.html (or any file) in that folder.

5. Check status

    git status
   

   Git sees the new file as "untracked."

6. Stage the file

    git add .
   

7. Review what you're about to commit

    git diff --staged
   

8. Save the snapshot

    git commit -m "Initial commit"
   

9. Repeat the cycle

   • Edit files

   • git diff (see what changed)

   • git status

   • git add <files>

   • git diff --staged (review staged changes)

   • git commit -m "Explain the change"

10. Made a mistake?

    • Staged something by accident → git reset <file>

    • Last commit was wrong (not pushed) → git reset HEAD~1

    • Need to undo a pushed commit → git revert <hash>

Later, when you create a remote repository (e.g., on GitHub), you'll add it and push there ( more on that later), but just as an example:

git remote add origin https://github.com/yourname/my-app.git
git push -u origin main

Now your local work is backed up and shareable.

Just to give the gist in one pic:

---

Final Thoughts

I hope i was able to make the topic of Git a little bit easier. It is not just a tool, it's a mindset shift. It takes you from "I hope this works" to "If it breaks, I'll fix it." It turns coding from a tightrope walk with no safety net into a series of safe, reversible steps.

So start small. Commit often. Name your commits clearly. Use branches to experiment.

Git will remember everything - so you don't have to.

Uffff…. my fingers hurt now….

Too much gyan today….

See you next when new gyan is acquired….

Ohhh i almost forgot about the links, so here they are :

• https://youtu.be/RDxQEzXN8AU?si=rEpYKLz7En_RoIpk

• https://youtu.be/q8EevlEpQ2A?si=v_Xo0FXwfpDg69PE

• https://youtu.be/zTjRZNkhiEU?si=HrpVUXLUDcyyWA5y

If you found this article helpful, share it with others and feel free to leave your feedback—I’d love to hear your thoughts!