Git is a DVCS (Distributed Version Control System) that helps you manage different versions of a software being developed. It is easy to use when you know about it, it really helps in managing different versions of a software and revert to versions when required.

Why Git is used?

Git is used to manage different versions of a software, helps multiple users to code at the same time, make different branches like “main” for stable code and make another branch for a new feature named “new-feature” or something and their you can experiment with all your new ideas, after your experiment is done and you like it you can merge the two branches “main” and “new-feature” into one, and talking about versions of a software we can also revert one version of a software to previous version of the software if required.

Git Basics and Core Terminologies

The basic 4 Pillars of Git are :-

1. Initialize a git repo in the project, modify the files in current directory.

2. Stage all the changes using “git add” command for the next step “commit”.

3. Commit all the changes using “git commit -m “[message]”.

4. Push all the changes to remote repository from local repository for enhanced sharing.

The core terminologies of git are :-

1. Repository: A repository (repo) is a folder containing all the important files for the project, there are two types of repositories :-

   • Local Repository

   • Remote Repository

2. Commit: A commit is like a snapshot of your code and a specific time. Each commit has its own SHA-1 HASH for its uniqueness.

3. Branch: Branches are two codebases in a single repo. It works like one repo is “main” where the latest and most sustainable is and on the other hand is a secondary branch named like secondary or something where you experiment with new features without touch the main branch.

4. Staging area: staging area is where files wait before commit

5. HEAD: HEAD is a pointer to current branch or commit where you are currently working.

Common Git Commands

How Git Works Internally**

Git works by storing files as blobs (content with hashes), directories as trees (listing files), and snapshots as commits (with history links), all in .git/objects. Branches are refs pointing to commits, the index stages changes into trees, and everything is immutable with content-based names for safety and efficiency.

Understanding the .git folder

The .git is the folder where git stores all the information about the git repository: “objects” folder saves files (blobs), folders (trees), and versions or commits by their hash; “refs” folder points branches or tags to versions; HEAD shows where you are; index holds staged files; config sets options; “logs” folder tracks moves; “hooks” folder runs scripts. We should never delete or edit it manually, as it can ruin the whole project.

Git Objects: Blob, Tree, Commit

Git objects are simple: blobs hold contents of the files, trees show structure of the folder, and commits save a full project picture with history details.

Blobs: Raw file data only—no names. Hash = unique ID. Same content = same blob.

Trees: Like a folder list: file names, types, and their blob/tree hashes.

Commits: Point to root tree + parents + who/when/message. Snapshots, not changes.

How Git Tracks Changes

Git tracks changes simply by taking full snapshots of your entire project with every commit, instead of just the edits. Each snapshot is a complete picture of all files at that moment, stored nicely through shared hashes. When you ask for differences—like with git diff or git log -p—Git smartly compares these snapshots to show what changed between them. The process flows through your working files, staging with git add (which prepares the snapshot pieces), and committing to save it permanently.

Version control system (VCS) is used to track changes in your code and code files systematically. It helps in making different versions of a program. It can also revert to previous versions of a software, if there was a flaw in the current or some other version of the software.

The Pendrive Analogy in Software Development

Before version control systems, developers used USB drives or pendrives to collaborate. They shared one common USB drive with all the project files. Only one coder could code at a time.

If another coder changed something in his copy of the code, everything went out of sync. It could make a total mess.

They made folders named "final", "final_v2", "latest final", etc to make different versions of a software. This included manual folder making and extra work for just making different versions of a software.

These problems were faced by millions of coders. They couldn't collaborate and code at the same time. They couldn't make different versions of a software. Instead they had to make different folders for different versions.

Problems Faced Before Version Control Systems

These were the problems faced before version control systems:

1. Accidental Overwrites: When multiple people edited the same file, one developer could easily overwrite another's changes without noticing.

2. Version Chaos: Without VCS, developers couldn't make different versions of a software without making folders like "final_v2", "latest_final", etc.

3. No Change History: It was somewhat impossible to track who made specific change, what was the time when they were made, or why, making it difficult to identify bugs.

4. Difficulty Undoing Changes: When there was no version control systems reverting to previous version of a software was a nightmare.

5. Collaboration Inefficiency: When developers wanted to collaborate they had to make some different folders and sometimes share a USB drives and imagine the USB drives as the single source of truth. If any other coder (which doesn't have the USB drives) made changes in his copy of the project everyone goes out of sync and it can make a huge mess.

6. High Risk of Data Loss: If a single computer or shared drive crashes, the entire project and its history could be lost forever. If one of the shared drives like USB drives, etc. crashes it can cause a whole data loss.

7. Fear of Experimentation: Without git, which includes branching, early developers had the fear of experimentation because a bug can cause whole project to crash.

8. Complicated Deployment: Without a clear "main" branch, identifying which specific set of files was ready for production and can be launched without any manual work which was difficult.