Git Version Control: Track Every Change

Four Files, One Presentation, Zero Idea Which Is Right

Six students in Class 8 are building a presentation for their school's Independence Day assembly. Priya writes the introduction and emails the file to the group. Arjun adds three slides about freedom fighters and sends back a new file, unsure whether typing directly into Priya's copy is allowed. Meera fixes a spelling mistake in Arjun's version and, not realizing a newer copy already exists, saves her fix as IndependenceDay_FINAL.pptx. By Thursday evening, the group's shared WhatsApp folder holds five files: IndependenceDay.pptx, IndependenceDay_v2.pptx, IndependenceDay_FINAL.pptx, IndependenceDay_FINAL_edited.pptx, and IndependenceDay_FINAL_USE_THIS_ONE.pptx. Nobody can say for certain which file holds everyone's latest work, whether Arjun's slides made it into Meera's edited copy, or what to do if the "final" version turns out to have a mistake that an earlier version did not.

This exact scramble happens to software teams as well, except instead of six students and one presentation, imagine thousands of engineers spread across different cities and time zones, editing the same enormous codebase at the same time. A single naming mistake could delete someone's afternoon of work, or ship a broken product to millions of people. The tool that solves this problem, for student groups and large engineering teams alike, is called version control, and the most widely used version control tool in the world is called Git.

Beyond Ctrl+Z: What "Version Control" Really Means

You already use a basic form of change tracking every time you press Ctrl+Z in Word or PowerPoint. Undo remembers your last few actions and lets you step backward through them. But Undo has three real limits. It only remembers what happened in your current session, so closing the file and reopening it erases that history. It never records why a change was made. And it has no idea that four other people might be editing the same document from four other devices.

Version control is software that solves all three problems at once. It permanently records every saved change to a set of files, along with who made the change, when they made it, and a short message explaining why. Nothing is silently lost. You can jump back to exactly how your project looked at any earlier point, compare two points in time line by line, and combine work from multiple people without anyone's changes overwriting anyone else's by accident.

Git is a specific piece of version control software, and understanding how it works from the ground up pays off quickly. Instead of remembering only what changed between two versions of a file, the way track changes does in a word processor, Git saves a complete snapshot of every tracked file in your project each time you save your work. Picture a photograph of your entire project folder, taken at one instant. If a particular file did not change since the last photograph, Git is efficient enough not to store that content twice, but conceptually, every save gives you a full, self-contained picture of the whole project at that moment, unlike older systems that only jot down what changed between versions.

Where Git Came From

Git was created in 2005 by Linus Torvalds, the Finnish software engineer who had already created the Linux operating system kernel back in 1991. By 2005, thousands of developers scattered across the world were contributing code to Linux, and the tool the project had been using to manage those contributions suddenly became unavailable to them. Torvalds needed a replacement fast, and it had to handle a challenge few tools of that era were built for: huge numbers of contributors, working from different countries, with no single reliable central server everyone could always reach.

His solution was a distributed version control system. In a distributed system, everyone working on the project keeps a complete copy of the entire history on their own computer, including every saved version that ever existed, all the way back to the first commit. No single computer's failure can wipe out the project's memory. Torvalds wrote the first working version of Git in about ten days, and within that same month the Linux kernel itself switched to using it for real development. Linux still uses Git today, and so does the great majority of professional software teams around the world, including most Indian technology companies and startups, from large IT services firms to product companies in Bengaluru and Hyderabad.

The name itself is characteristically blunt. Torvalds has joked that he names his projects after himself, immodestly: first Linux, then Git. "Git" also happens to be British slang for an unpleasant or foolish person, and Git's own documentation leans into the joke, describing the tool, only half seriously, as "the stupid content tracker." It is an odd name for a tool now considered essential infrastructure across the software industry.

The Three Places Your Work Can Live

Before touching a single command, three areas are worth understanding clearly, because confusing them trips up almost every beginner.

• The working directory is the actual folder on your computer, containing the actual files you open and edit, exactly like any other folder.
• The staging area (Git also calls this the index) is a holding zone where you list exactly which changes you want included in your next save.
• The repository (often shortened to repo) is Git's permanent record: the full history of every snapshot you have ever saved, stored in a hidden .git folder inside your project.

Think about the last time you shopped on an app like Flipkart or Amazon. Browsing products and adding things to your basket does not charge your card; it is just deciding what you might want. That browsing stage is your working directory: you can edit a file, delete a paragraph, or add a new slide, and none of it is recorded anywhere yet. Choosing "Add to Cart" is like running the command git add: you are deliberately selecting exactly which changes should be included in your next save, even if you have touched five other files you are not ready to include yet. Only when you tap "Place Order," the equivalent of running git commit, does anything become permanent. That action creates a commit: a permanent, timestamped snapshot of exactly the changes you staged, along with a short message explaining what you did and why. Placing an order generates a receipt with an order number you can look up forever in your order history; a commit generates a unique ID you can look up forever with the command git log.

Setting Up a Repository, Step by Step

Suppose Priya decides to stop emailing files back and forth and starts tracking her Independence Day speech with Git instead. Every command below is typed into a terminal. Lines starting with $ are what Priya types; the lines beneath are Git's reply.

First, she turns an ordinary folder into a Git repository:

$ mkdir independence-day-speech
$ cd independence-day-speech
$ git init
Initialized empty Git repository in /Users/priya/independence-day-speech/.git/

git init creates a hidden .git folder that will hold the entire history of the project from now on. Nothing has been saved into that history yet; the repository exists, but it is empty. Priya then creates a plain text file called speech.txt and types two opening lines. Checking the repository's state with git status shows:

$ git status
On branch main
No commits yet

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

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

Git has noticed the new file sitting in the working directory but calls it untracked: Git is not yet watching it for changes, because Priya has not told it to. (Most computers today are set up to name this starting branch main by default, which is what appears here; some older setups still call it master, and either name works exactly the same way.) She adds the file to the staging area and checks the status again:

$ git add speech.txt
$ git status
On branch main
No commits yet

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

The file has moved from untracked to "changes to be committed": it is sitting in the cart, ready to order, but the order has not been placed yet. Priya places the order:

$ git commit -m "Add opening lines of Independence Day speech"
[main (root-commit) a3f5c9d] Add opening lines of Independence Day speech
 1 file changed, 2 insertions(+)
 create mode 100644 speech.txt

Git confirms the commit with a short identifying code, a3f5c9d, a fragment of a much longer, unique fingerprint that Git generates for every commit, guaranteeing that no two commits anywhere will ever share the same identifier. The label (root-commit) appears only this once, because this is the very first commit the repository has ever recorded.

Tracing a Change from Edit to History

The next day, Priya adds a third line to her speech: a sentence about the sacrifices of freedom fighters. She saves the file and checks the status before doing anything else:

$ git status
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:   speech.txt

no changes added to commit (use "git add" and/or "git commit -a")

Notice the difference from before. This time Git says modified, not untracked, because speech.txt is already part of the repository's history: Git already has a snapshot of the old version and can see that the file no longer matches it. To see the exact difference, line by line, Priya runs git diff:

$ git diff
diff --git a/speech.txt b/speech.txt
index 4f2a891..8b3f21c 100644
--- a/speech.txt
+++ b/speech.txt
@@ -1,2 +1,3 @@
 Respected Principal, teachers, and dear friends,
 We gather here to celebrate the spirit of freedom that defines our nation.
+We remember today the courage of those who sacrificed everything for it.

Reading this output is a skill worth building on purpose. The lines beginning with --- and +++ name the old and new versions of the file being compared. The line @@ -1,2 +1,3 @@ is a hunk header: the old version showed 2 lines starting at line 1, and the new version now shows 3 lines starting at line 1. Lines with no symbol in front are unchanged context, kept so a human reader has something familiar to anchor to. A line starting with + is new; a line starting with - (none appear here) would mean a line was deleted. Priya stages and commits this change exactly as before:

$ git add speech.txt
$ git commit -m "Add line honoring freedom fighters' sacrifice"
[main f8e2c11] Add line honoring freedom fighters' sacrifice
 1 file changed, 1 insertion(+)

This commit message carries no (root-commit) label, because that tag only ever appears on a repository's very first commit. Checking the project's full history now shows both saved snapshots, most recent first:

$ git log --oneline
f8e2c11 Add line honoring freedom fighters' sacrifice
a3f5c9d Add opening lines of Independence Day speech

Two commands, two commits, and a complete, permanent, timestamped record of exactly how the speech grew: something no naming trick like _FINAL_v2 could ever guarantee.

Five commands now cover most of what Priya needs day to day:

• git init: turn a folder into a repository, once.
• git status: check what has changed and what is staged.
• git add <file>: stage a change, choosing exactly what to include.
• git commit -m "message": save a permanent, labeled snapshot.
• git log: see the full history of every snapshot ever saved.

Undoing Mistakes: Git as a Safety Net

The night before the assembly, Priya is editing the speech and accidentally deletes an entire paragraph while trying to fix a typo nearby. She has not yet staged or committed the deletion. She runs git status and sees the familiar modified message. Because the deletion was never staged or committed, the last good version of the paragraph still exists safely inside the repository's history; only the working directory copy is broken. She can throw away every uncommitted change in the file and restore it to match the last commit with a single command:

$ git restore speech.txt

The paragraph reappears exactly as it was in the last commit. As long as work has been committed, it is essentially unlosable. Even mistakes that do get committed are not permanent disasters: every earlier snapshot in git log stays fully intact and can be examined or restored, because Git never overwrites or deletes old snapshots when a new one is created. Word's Ctrl+Z forgets everything the moment a file closes. A Git commit is remembered forever by design, whether the computer is shut down, restarted, or handed to someone else entirely.

Branches: Trying an Idea Without Risking the Original

Two days before the assembly, Arjun wants to rewrite the speech's ending in a more dramatic style, but he is not confident it will actually be better, and he does not want to risk breaking the version that already works. Git's answer to this situation is the branch: a separate, parallel line of development that starts as an identical copy of the project but can be edited independently, without touching the original at all.

$ git switch -c dramatic-ending
Switched to a new branch 'dramatic-ending'

Arjun is now working on a branch called dramatic-ending, while the project's main branch (by convention usually named main) sits untouched, exactly as the group last agreed on it. He edits the closing paragraph and commits the change on this branch just as before. If the group likes the new ending, they switch back to main and combine Arjun's branch into it:

$ git switch main
$ git merge dramatic-ending

Merging combines the two branches' histories, bringing Arjun's committed changes into main. If the group decides the original ending was better, they simply keep using main and leave the dramatic-ending branch alone, or delete it. Nothing about the original speech was ever at risk, because the experiment lived on its own separate line of history the entire time.

From One Laptop to a Whole Team: Git and GitHub

Everything described so far happens entirely on one computer. Git does not need an internet connection to initialize a repository, stage changes, commit, or view history. But Priya's group has six members, and a repository sitting only on Priya's laptop does the other five no good. This is where a remote comes in: a copy of the repository hosted on a server elsewhere that every group member can synchronize with.

The most widely used platform for hosting Git repositories online is GitHub, founded in 2008 and now owned by Microsoft. Uploading a local repository's history to a remote for the first time, and later synchronizing new commits, uses two commands built directly into Git. Running

$ git push origin main

sends any new local commits up to the shared copy on GitHub, and running

$ git pull origin main

downloads any commits teammates have pushed since the last sync, merging them into the local copy. A teammate joining the project for the first time does not start from an empty folder at all. They run git clone followed by the repository's address and receive the entire project, along with its complete commit history, in one step, exactly as if they had been there from the first commit.

GitHub adds features on top of plain Git that make teamwork smoother still. The most important is the pull request, which lets a contributor propose their committed changes for review before those changes are merged into main, so teammates can read the diff, leave comments, and catch mistakes before they become permanent. It is, in effect, a far more disciplined version of what Priya's group was trying to do by hand with file names and WhatsApp messages, except every proposal, comment, and decision is itself recorded and traceable, forever.

Back to the Group Project

Had Priya's group used Git from the start, their week would have looked different. One shared repository would have replaced five confusingly named files. Every teammate's contribution would appear in git log with their name, the exact time, and a message explaining what they changed and why. Arjun's slides about freedom fighters would never have gone missing inside someone else's copy, because there would only ever have been one copy, with every change layered on top of the last in an order nobody could dispute. If Meera's edit had accidentally deleted a sentence, git diff would have shown exactly which line vanished, and git restore could have brought it back in seconds.

Version control does not remove the need for six people to talk to each other and cooperate. Git cannot decide which ending is better, or write the speech's opening line. What it removes is the fear of not knowing what changed, who changed it, or whether a better earlier version has been lost forever, the exact fear that IndependenceDay_FINAL_USE_THIS_ONE.pptx was always a symptom of. Every software team on Earth, from a two-person startup in Pune to the engineers still maintaining the Linux kernel Torvalds started in 1991, runs on the same guarantee Priya's group now has: nothing is ever truly lost, every change has an author and a reason, and the entire history of the project is always one command away, git log.

Key Takeaways — Summary and Recap

Let us recap what we covered: the core ideas behind git version control: track every change, how they connect to real-world applications, and why they matter for your journey in computer science. Remember these key points as you move forward. For competitive exam preparation (CBSE, JEE, BITSAT), focus on understanding the WHY behind each concept, not just the WHAT.