JavaScript mein agar kabhi setTimeout lagaaya, API call maara, ya database se data maanga hai… toh tum asynchronous JS jungle ke safari pe nikal chuke ho. 🌴🐒

Aur iss jungle ka ultimate raja — Promise. Aaj hum isko full desi college romance wale andaaz mein samjhenge. Proposal se shuru, lovey-dovey phase, aur akhir mein wo iconic breakup drama. ❤️→💔

Maza bhi aayega, concept bhi crystal clear hoga, aur thoda sa college nostalgia ka overdose bhi milega. 🥲

Technically 100% correct. Emotionally? 1000% relatable, bhai!

Promise hota kya hai?

Simple language mein:

Promise = Ek aisa commitment jo future mein ya toh fulfill hoga ya reject.

Ek future ka "pakka wala vaada" jo ya toh poora hoga (resolve), ya toh dhokha dega (reject).

Picture this:

College ka 2nd year mein padhte huye tum, freshers' party pe usko dekha. Tumhari aankhein aur dil dono uski smile ne chura le gaya. Dil se dil tak current chala gaya. Semester exams khatam hue, tumne himmat juta ke propose kar diye (roof-top pe, rain background mandatory).

Ab uska reply? Pending… pending… pending…

Exactly jaise JS ka Promise!

const pyaarKaPromise = new Promise((resolve, reject) => {
  const mutualVibes = Math.random() > 0.4; // reality check 😏
  if (mutualVibes) {
    resolve("YES bol diya! 💍✨");
  } else {
    reject("Bhai… sirf dost theek hai 🙂‍↔️");
  }
});

3 States of Pyaar (aka Promise States)

Chetan Bhagat ke 2 States padhe the? Forget that. Real college love mein sirf 3 states hote hain:

1. .then() – “Haan bol diya, ab shuru honeymoon phase”

Kyu ke Promise ek asynchronous activity hain, tumhara tension khatam hone mein kuch time to lagega bhai! Sirf success pe .then chalta hai. Jaise tumhari proposal accept hone ke baad wali story.

pyaarKaPromise
  .then((msg) => {
    console.log(msg); // "YES bol diya! 💍✨"
    // ab CCD date plan karo
  })
  .catch((err) => {
    console.log(err); // "Bhai… sirf dost theek hai"
    // sad playlist on repeat
  });

2. Promise Chaining – Full college love arc

Ek, do event pe nahi rukta na pyaar? Propose → first date → Insta official → late-night calls → trips → ghar waalon ko manana → shaadi dreams…

Same vibes chaining mein bhi:

Promise.resolve("Proposal accepted 💖")
  .then((msg) => {
    console.log(msg);
    return "First maggi date in canteen 🍜";
  })
  .then((date) => {
    console.log(date);
    return "Insta story daal di – #CoupleGoals 📸";
  })
  .then((status) => {
    console.log(status);
    return "Ghar waalon ko convince kar liya? Maybe… 😅";
  })
  .catch((error) => {
    console.log("Breakup loading…:", error);
  });

Har .then() ek naya Promise return karta hai aur har .then() previous step pe depend karta hai. Ek bhi fail → chain crash!

3. .catch() – The ultimate breakup catcher

Beech mein ex wapas aa gaya, trust issues, ya "long distance nahi chalega"… wajah kuch bhi ho, aap ko .catch() samhalta hain.

Promise.resolve("Honeymoon phase on 🔥")
  .then(() => {
    throw new Error("Ex ne story pe like kar diya 😵");
  })
  .then(() => console.log("Ye nahi hoga"))
  .catch((drama) => {
    console.log("Relationship terminated:", drama);
  });

.catch() poori chain ke errors ko pakad leta hai. Jaise ek bhi red flag dikha → pura pyaar red zone mein!

4. .finally() – “Pyaar gaya toh gaya, placement toh lagana hai”

Chahe resolve ho ya reject, ye hamesha chalega.

Promise.reject("Seen-zoned forever 🥲")
  .catch((err) => console.log(err))
  .finally(() => {
  // Pyaar mile na mile, placement milna chahiye..
 //Ya to Uski choice ko duniya ke nazro mein prove karne ke liye 😎,
//Nehi to uske decision ke against self-worth prove karne ke liye... 😭
    console.log(" ChaiCode webdev cohort enroll karte hain");
    console.log(" 😎  placement loading...");
  });

Promise Static Methods – Multiverse of College Crushes

Promise.all() – “Ladka Approval Committee”

"Sabki approval chahiye"
Bestie, uski bestie, mummy-papa… sab yes → green signal. Ek bhi no → poora reject!

const bestFriendApproval = Promise.resolve("Best friend happy");
const herBestieApproval = Promise.resolve("Her bestie approved");
const momApproval = Promise.resolve("Mummy ko bhi pasand");

Promise.all([
  bestFriendApproval,
  herBestieApproval,
  momApproval
])
.then((results) => {
  console.log("Sab khush:", results);
})
.catch((error) => {
  console.log("Kisi ko problem hai:", error);
});

Promise.allSettled() – “Sab apna apna opinion batao”

Chahe koi support kare, koi hate kare, sabka status milega. Real gossip group energy.

const friend1 = Promise.resolve("Supportive");
const friend2 = Promise.reject("Toxic banda hai");
const friend3 = Promise.resolve("Neutral");

Promise.allSettled([friend1, friend2, friend3])
  .then((results) => {
    console.log(results);
  });

Output Structure:

[
  { status: 'fulfilled', value: 'Supportive' },
  { status: 'rejected', reason: 'Toxic banda hai' },
  { status: 'fulfilled', value: 'Neutral' }
]

Promise.any() – "Bas ek haan chahiye yaar"

Thoda controversial 😜 hain but tum concept samjho..bhawnao pe mat jao..😉. Multiple crushes mein se pehla yes → jeet gaye! Sab reject → total heartbreak (AggregateError).

Rule:

• Pehla resolve → success

• Sab reject → AggregateError

const crush1 = Promise.reject("Already committed");
const crush2 = Promise.resolve("Interested 👀");
const crush3 = Promise.reject("Friendzone");

Promise.any([crush1, crush2, crush3])
  .then(console.log)
.catch(console.log);

Promise.race() – "Kaun pehle reply karega?"

Jo sabse jaldi message karega, wahi jeetega. DM race intensifies! 🏃‍♂️💨

const instaReply = new Promise((resolve) => {
  setTimeout(() => resolve("Insta pe reply 💬"), 1000);
});
const whatsappReply = new Promise((resolve) => {
  setTimeout(() => resolve("WhatsApp pe reply 📱"), 2000);
});
Promise.race([instaReply, whatsappReply])
  .then(console.log);

Deep Concept: Error Propagation

Error kahin bhi aaya, neeche .catch() tak pahunch jaata hai. Jaise "trust issues" ka chhota sa seed → pura relationship ko barbaad karta hain.

Agar chain mein kahin bhi error aaya, woh neeche ke .catch() tak travel karega.

Promise.resolve("Start relationship")
.then(() => {
return Promise.reject("Trust issues 😬");
})
.then(() => {
console.log("Ye kabhi nahi chalega");
})
.catch((err) => {
console.log("Handled:", err);
})

Output:

Handled: Trust issues 😬

Bonus: async/await – Mature, thoda calm wala version

Sabar ka fal, meetha hota hain! Ab yeh dekho promises ke liye wait karne ka mature tareeka.

async function collegeLoveStory() {
  try {
    const proposal = await Promise.resolve("YES! 💖");
    console.log(proposal);

    const firstKiss = await Promise.resolve("Movie theatre mein popcorn share 🍿");
    console.log(firstKiss);

    const future = await Promise.resolve("Couple DP forever ✨");
    console.log(future);
  } catch (heartbreak) {
    console.log("Breakup scene:", heartbreak);
  } finally {
    console.log("Life goes on… next sem ke notes bhi padhna padenge 🌈");
  }
}

collegeLoveStory();

Final Gyaan (Technical + Dil se)

• Promise = future ka dabba (value ya error)

• .then() = happy ending chain

• .catch() = breakup damage control

• .finally() = placement grind never stops

• all / race / any / allSettled = alag-alag desi love scenarios

Aage se jab koi bole “Baby, I promise…”

Tu seedha bol dena:
“Return type bata?
Resolve ya reject?
Aur .catch() hai kya? 😏🔥”

Ab jaao, promises samajh ke code likho… aur thoda sa college wala pyaar yaad karke smile kar lo. ❤️‍🩹😂

Jai Hind!

Abhirup

Git works flawlessly—until it doesn’t. Merge conflicts, detached HEADs, corrupted repos—these problems become trivial once you understand how Git works internally. Many developers use Git every day, but treat it like a black box

Hi! My name is Abhirup Roy, I build softwares and write about them. Today I am writing a concept-first article designed to help you understand Git internally, not just use it. The goal is to help you build a mental model of Git—how it thinks, stores, and protects your code - so Git commands feel logical instead of magical.

The .git folder serves as Git's database, storing all repository metadata, history, and objects to track your project's evolution without relying on external servers. Understanding its structure and contents reveals how Git maintains snapshots of your work efficiently. This mental model shifts focus from commands to Git's content-addressable file system.

This article explains:

• What the .git folder really is

• How Git objects (blob, tree, commit) work together

• What actually happens during git add and git commit

• How hashes guarantee integrity

• Why Git tracks content, not files

No memorization. Only mental models.

Main Premise: A Content-Addressable File system

Before diving into the folders, we must understand the fundamental paradigm of Git.

Git is fundamentally a content-addressable file system layered with a directory tree structure.

What does that mean? Most systems store data based on where it is (e.g., C:/Documents/report.txt). Git stores data based on what it is.

Git takes a piece of data (like the contents of a file), runs it through a hashing algorithm (SHA-1), and generates a unique 40-character string (the hash). Looks like: 6f5d4e3....

Why is this crucial?

1. The hash is the identity: Git doesn't care that your file is named index.html. It only cares about the hash of its contents.

2. Integrity is guaranteed: If you change a single character in a file, the resulting hash changes completely. It is impossible to corrupt file contents or alter history without Git knowing about it, because the hashes wouldn't match anymore.

3. Deduplication: If you have two files with identical contents in different folders, Git only stores the content once, because they share the same hash.

The Engine Room: The .git Folder

Git is a database of snapshots, not diffs

What is the .git Folder? The .git folder is the Git repository itself. Everything Git knows - history, branches, commits, staging, tags—is stored inside .git.

If you delete the .git folder, your project becomes a normal folder again.

Why Does the .git Folder Exist? Git in over-simplified term, is a content-addressed database plus a versioned file system.

• Your working directory → files you edit

• .git directory → Git’s internal database

Git never relies on filenames or timestamps. It relies on content hashes.

When you run git init in a directory, Git creates a hidden folder named .git. This folder is your repository. Your working directory (where you edit files) is just a temporary checkout of data managed inside the .git folder.

While it contains many configurations, these are the critical components for understanding internals:

• objects/: This is the heart of Git. This is the database where all your files, commits, and trees are stored, referenced by their hashes.

• refs/: This is where Git stores bookmarks to specific commit hashes. Branches (like main or develop) and Tags are just files in here containing a single hash.

• index: (Also called the "Staging Area"). This is a binary file that acts as the crucial middleman between your working directory and the repository. It builds the next commit.

• HEAD: A pointer indicating "where you are right now." It usually points to a branch name inside refs/.

Git Objects: The Atoms of History

Git stores everything as immutable objects, each identified by a unique SHA-1 hash (40-character hex from content), ensuring integrity—if content changes, the hash changes. Inside the .git/objects directory, Git stores everything using three main types of objects. Don't think of changes as "diffs"; think of them as snapshots built from these three blocks. Three core types form a hierarchy: blobs (file contents), trees (directory snapshots), and commits (named snapshots with metadata).

1. Blob: The simplest object. A blob contains just the contents of a file. It does not know the file's name, its permissions, or when it was created. It is just raw data compressed and hashed. Raw file content, no filename or history stored—just bytes with a hash like da39a3ee5e6b4b0d3255bfef95601890afd80709.

   • Analogy: A Polaroid photograph. It shows an image, but nothing is written on the white border.

2. Tree: Blobs aren't enough. We need filenames and directory structures. A Tree object solves this. A Tree is essentially a list of directory contents. Each line in a Tree object maps a filename to the hash of a Blob (for files) or another Tree hash (for sub directories). Directory listing with name, mode, and hash references to blobs or sub-trees, e.g., representing "file.txt" pointing to its blob hash.

   • Analogy: A folder on your computer desktop that contains photos (blobs) and other sub-folders (other trees).

3. Commit: Snapshot via tree hash, plus metadata (author, date, message, parent commits), forming history chains.

This design enables deduplication—identical file content reuses the same blob hash across the repository.​

Hello! My name is Abhirup Roy, I build softwares and I write about them. Though we engineers have a special fond for fancy technical terms, I prefer simplicity over jargons. Let’s dive back to our Computer Networks 101 and understand essential network devices in a TL;DR fashion with real-life examples and easy to visualize analogies.

Today’s computer network, is built on a design strategy where a computer network has been segregated in groups, in such a way, that our data flow is contained within these groups. Bigger the geographical area the network covers, more iteration of this design, resulting in multiple copies of these network groups. These groups are -

• WWW User Devices

• Local Network

• Enterprise Network

• ISP Edge

• Internet Backbone

• Datacenter

Each of these groups have their respective role in establishing and maintaining data flow, and in order to do that, each of these groups use few network devices. Thus these are the most common and will be part of this discussion. Remember, internet is an ongoing evolution from ARPANET project in 1969, to transition to official internet with standard TCP/IP protocol allowing different networks to connect, happened on January 1, 1983, and each component used in internet has its scope of diving very deep (from hardware implementation to software abstraction of each network device used). But in this article, my objective is to explain network device and how they make computer network work, without getting into “rabbit hole”, hence TL;DR approach.

Before I explain the above network architecture, first I want to talk about another concept, that we need to refer to in our journey to understand computer networking. Open Systems Interconnection AKA OSI model. It is a conceptual framework that segregate/standardize network communication functions/operations into manageable stages (🤯😵‍💫).

Basically it is a 7-stage layered approach in which computer network communication happens. So, at each layer, which ever networking function is performed, its relevant hardwares and few rules that these hardwares follow to operate, are involved. I have prepared a diagram to show you that at each of 7 layers of OSI framework, certain network functions are performed by respective hardwares, using respective protocols (in simple term, rules).

• Physical layer AKA Layer 1 handles raw electrical and optical signals. Hence devices that works at this layers not “intelligent” enough to understand IP address and MAC addresses. Hence, they take incoming electrical signals and send them out to all devices after performing its duties. In this layer we have below devices -

  1. Hub - A central connection point for devices in a LAN. It takes an incoming signal on one port and blindly broadcasts it to all other ports. This leads to collisions when multiple devices try to talk at once, reducing efficiency and security risks (everyone sees everyone's data). Preferably, in real-life, hubs are avoided as switch is a better alternative.

  2. Repeaters - A repeater is a network device that regenerates weakened or corrupted signals to restore them to their original form before re-transmission. Unlike an amplifier, which increases both signal and noise, a repeater reconstructs the original clean signal and forwards it, ensuring reliable data delivery over longer distances.

  3. Modem - Is an abbreviation of two words - Modulator and Demodulator.

As we embark on our long and arduous journey of learning to code and build complex softwares that can solve real-world problems, the first inevitable bump that we come across is learning Git, the “version control software“ for all the codes and other important files, used in a project.

Hi! my name is Abhirup Roy, I love to build softwares and write about them, and today, in this article, we are going to understand how to use Git, enough to get going. We can always dive deeper later, to master our understanding of the software, from its internal architectures to design strategy and principles used in implementation, and discuss all the mostly used functionalities that Git provides us. But before we can dive that deep, today, in thing article, we will learn how to at least start using Git to track our code changes, like how “pro” engineers do in their production software projects.

Before explaining the “how” part, Let’s have an overview idea about “what is Git?” and '“why should we use git?”

What is Git

In one word over-simplification, Git is the “Undo“ option for software developers!

Like any other projects, a software project is an implementation of an answer to a real-world problem. When we create such a software project, it is obvious, that we need to write many lines of code, often segregated in different files, to keep the design clean, understandable, maintainable and upgradable.

While we do so, we create many files, edit many files, sometime even remove few files to reach to the final version of our solution of the problem. It is quite understandable that, this cannot be done in a single attempt, or most often, not by a single software programmer. Thus, we need an efficient way to track changes in our project files and also provide a mechanism to enable multiple programmers to contribute their progress to the project code base to reach the final implementation of solution. Git does that for us. It is a “distributed version control system“ software. Let’s dissolve the jargons, “version control system” means, it keeps a track onto each programmer’s code changes along with timestamp onto their workstations, and, “distributed“ refers to the ability of Git to allow programmers to submit their delta progress to a central source code storage of project (which is often a remote server), documenting it with an ID, a description, contributor’s name or email and timestamp of contribution.

Why should we use Git

As we got a bird view idea around what is the purpose of Git version control software, let’s also skim through why should we use Git, or any VCS (version control system) software for the matter.

Git is used to track, manage and co-ordinate changes in software project files (i.e. codes and other files) efficiently, when a team of software engineers are working on the same project.

• Complete change history tracking by recording author, timestamp and commit message

• Easy rollback and debugging in case of errors introduced

• Each repository or in short repo, is a full backup of the project, containing all files. Thus, multiple software developers can work on the same repo simultaneously, by working offline and upload their delta change to the repository. In most of the real-world scenarios, we software developers use a remote repository in online platforms like GitHub, BitBucket or GitLab, so that we do not have a single point of failure

• Creating branches in Git for experimenting some new risky or experimental changes without jeopardizing entire project’s progress. Creating branches in git is lightweight and fast, enabling developers to develop new features, fix bugs and experiment in their codes. Merging these back to the original main or master branch is also reliable and traceable

If you want to dive deeper and understand why version control system(VCS) softwares exist in the first place and how VCS has evolved from a local change tracking tool to modern day distributed VCS - “Git”, you can read my another article - Why version control exists?

How to Install Git onto your system

• Check if Git is installed -

  1. Open a terminal for Linux or Mac OS, a command prompt/PowerShell/GitBash window, depending upon your OS.

  2. Run a command git --version , if Git is installed onto your system already, you will see Git version information onto your terminal/command prompt.

     

     If Git is not already installed onto your system, you will get a prompt response like command not found or ‘git’ is not recognized as an internal or external command

• Install Git -

  1. Installing Git on Linux -

     • For Debian based Linux distribution such as Ubuntu -

       1. Updates the package list using sudo apt update

       2. Installs git - sudo apt install git -y

       3. verify installation git --version

     • For Fedora, CentOS or RHEL -

       1. sudo dnf install git -y

       2. git --version

     • For Arch Linux -

       1. sudo pacman -S git

       2. git --version

     • For OpenSUSE -

       1. sudo zypper install git

       2. git --version

  2. Installing on MacOS -

     • Check if homebrew is available on your Mac -

       brew --version

     • Install homebrew if the above command does not show you homebrew version -

       /bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/HEAD/install.sh)"

     • Once the brew installation is comeplete and you get to see brew version information on brew --version command, install git using following command

       brew install git

       git --version

     • If the above method seems complex to you, you can also install git from GUI installer package. For that. follow below steps -

       1. Go to: git-scm.com

       2. Download macOS installer

       3. Run .pkg file

       4. Follow installation steps

       5. Verify with: git --version

  3. Installing on Windows -

     • On Windows OS, Git installation is GUI based and easy. Follow below steps -

       1. Visit: git-scm.com

       2. Click Download for Windows

       3. .exe file will be downloaded to your system

       4. During installation -

          • Keep the default/recommended options/settings

          • Make sure to select the option on GUI screen, that says - “Git from the command line and also from 3rd-party software”

            This ensures that Git will work on command prompt, PowerShell and editors or IDE like VS Code or IntelliJ

       5. After installation, open Command Prompt or PowerShell and run: git --version

• After installing Git onto your system for the first time, you will need to configure your identity in git -

  git config --global user.name “Your Name/Name that you want to use in your commit signatures“

  git config --global user.email “Your email - your.email@example.com“

  Once they are configured, you can always see them by running git config --global --list command

  

Core Terminologies and Concepts

Think of Git as three zones or areas: Working directory (your files), Staging area (prepare changes) and Repository or repo (saved history).

1. Working Directory: Current files you edit

2. Staging Area: git add moves changes here for review

3. Repository: A repository or simply ‘repo‘ is a Git-managed project.

   It contains:

   1. Your project files

   2. Full history of changes

   3. Git metadata inside .git folder

Types of repo:

1. Local repo → On your computer

2. remote repo → on GitHub/GitLab/BitBucket etc

4. Commit: A commit is a snapshot of your project at a point in time created by command git commit -m "Message". You can think of commit as “Save game checkpoint“. Each commit has:

   • Unique ID (hash created using SHA-1 encryption algorithm)

   • Author

   • Timestamp

   • Message (why the change was made)

5. Branch: A branch is an independent line of development.

   • main or master is the default branch

   • Feature branches allow safe experimentation

     Example - Trying to implementing login feature, onto feature branch, while, main branch is unchanged.

     

6. Head: Head tells Git -”This is where I am right now”. Head is a pointer to -

   • The current branch

   • The latest commit you’re working on

Git Managed Project Structure

Below is a tree-like representation of a simple, git-managed JavaScript based application project structure, for ease of understanding.

• .git/ → Git’s brain. Do not manually make any change to this directory, if you do not wish to unknowingly corrupt your project repo snapshots.

• File outside .git/ → Is your actual project. In the above diagram, src/ and README.md are your project files, while content inside .git/ is not.

Common Git Commands

• Initialize a repo: Start in an empty project folder. Open terminal there. Initialize a Git repository using the command :

    git init 
    # It creates a hidden .git folder tracking changes. Your folder has now a local repo.
  

• Check Status: Use below command to show modified, staged, or untracked files:

    git status
    # It shows modified, staged, or untracked files
  

• Stage and Commit Changes: Create/edit files, then :

    git add filename.txt # Stage one file 
    git add . # Stage all 
    git commit -m "Initial commit"
  

  The message describes the snapshot.

• View History:

    git log --oneline
    #Lists commits with short IDs and commit messages
  

• Undo Changes: Cover safe recovery with git restore for unstaged edits, git reset for unstaged commits (with caution), and git revert for committed changes. Emphasize checking git status first to avoid mistakes.

    git restore filename.txt  # Discard edits
    git checkout -- filename.txt  # Alternative
  
    #safe for unstaged files.
  

Save snapshot to remote repo: Connect to a remote repo like GitHub/GitLab via git remote add origin, git push to upload, and git pull/git fetch to sync. But for that to work, you definitely need to first create an account and perform first push.

git push origin main # publishing latest snapshot from local repo to remote repo
git pull # get the local repo in sync with remote repo

Summary of most common git commands based on their use case:

Developer Workflow

In the below illustration, I am giving a step-by-step example to give you an idea on a common workflow that a developer has to go through in his/her day-to-day software development work. However, there are many other corrective steps and actions that are used in cases of fixing wrong/corrupted project snapshots or mapping the snapshots to relevant branches. That are not topic of basics understanding, hence out of scope for this blog.

# 1. Create project folder
mkdir my-app
cd my-app

# 2. Initialize Git
git init

# 3. Create a file
echo "Hello Git" > app.txt

# 4. Check status
git status

# 5. Stage file
git add app.txt

# 6. Commit
git commit -m "Initial commit"

# 7. View history
git log

What Just Happened?

• Git started tracking your project

• File was staged and committed

• History is now preserved forever

What is Next?

Now let’s understand the developers workflow with git, how git works at local level as well as at the remote repository of single source of truth. In order to do so, let us refer the below flow diagram:

The above diagram shows a typical modern Git + GitHub/GitLab/BitBucket workflow from local development to CI/CD and deployment. Each step both structures the work and protects quality.

Step 1–2: Sync and Create a Feature Branch

1. git pull origin main (update local main) – The developer first synchronizes the local main branch with the remote repository to ensure they build on the latest code, reducing later merge conflicts.

2. git checkout -b feature-branch (create & switch to branch) – A dedicated branch isolates the new feature or bug fix, keeping the main branch clean and deployable at all times.

How this helps:

• Conflicts are minimized because everyone branches from a common, up‑to‑date base.

• main remains stable, which supports trunk‑based development, GitHub Flow, or Git-flow style workflows.

Step 3–5: Develop, Stage, and Commit Locally

1. Develop code & run local tests – Work happens entirely on the local clone; developers can iterate, refactor, and run tests offline without impacting others.

2. git add <files> (stage changes) – Staging lets developers build a precise set of changes into each commit, grouping related edits together.

3. git commit -m "message" (commit changes) – Each commit records a snapshot plus a descriptive message, creating a clear, review-able history for future debugging and auditing.

How this helps:

• Local commits are fast and independent of network latency.

• Fine‑grained commits with good messages make code review and rollback straightforward.

Step 6: Push Branch to Remote

1. git push origin feature-branch (push branch to remote) – The feature branch is uploaded to GitHub/GitLab/BitBucket so others can review and CI pipelines can run.

How this helps:

• Work becomes shareable and visible to teammates.

• CI systems connected to the remote repo can automatically build and test the branch.

Step 7–8: Open Pull Request and Run Review + CI

1. Create Pull Request (PR) against main – On the platform, the developer opens a PR (GitHub), merge request (GitLab), or similar in BitBucket, requesting that the feature branch be merged into main.

8a. Peer code review (approve/request changes) – Reviewers inspect the diff, comment on lines, suggest changes, and either approve or request revisions.

8b. Automated CI pipeline (build, lint, test) – CI runs the configured jobs (unit tests, integration tests, linters, security scans) on the branch and reports status back to the PR.

How this helps:

• PRs formalize peer review, improving code quality and knowledge sharing, especially for junior developers.

• Automated CI catches regressions early and blocks merges when tests fail, enforcing quality gates consistently.

Step 8 Decision: PR Approved & CI Passed?

“PR Approved & CI Passed?” – If reviewers request changes or CI fails, the developer returns to step 3, updates the code on the same branch, and pushes again; the PR and CI rerun automatically.

How this helps:

• Encourages iterative improvement until code quality and test coverage meet the team’s standards.

• Keeps broken code from ever reaching main, which stabilizes releases.

Step 9–10: Merge and Deploy via CD

1. Merge PR to main branch – Once approved and green, the platform merges the feature branch into main (often using squash or rebase strategies to keep history clean).

2. Automated CD pipeline (deploy to staging/production) – A CD pipeline triggers on changes to main, deploying to staging and/or production environments as configured.

How this helps:

• Merges are controlled and auditable, with a clear link from commits to reviews and issues.

• CD automates deployments, reducing manual errors and shortening time‑to‑production for each change.

Step 11: Sync Local After Deployment

1. git checkout main & git pull (sync local) – After the feature is merged and deployed, the developer switches back to main and pulls the latest state so the next feature starts from an up‑to‑date code base.

How this helps:

• Ensures the developer’s local environment matches what is in production or staging.

• Reduces future merge conflicts and keeps branches short‑lived, which aligns with modern Git-flow/GitHub Flow practices.

Conclusion

In this article, we got a step-by-step walk through on how to install git and also how to use git for tracking our software projects, to make software development journey easier and organized. The below diagram is the concept summary of git workspace stages and what actions are commonly performed at each stage

If you liked my article, you can subscribe to my blog and get notified, whenever I write a new article on other topics relating to software engineering.

Namaste! Jai Hind!

If you have ever worked on source code of any commercial software or any web or mobile app, it is pretty unlikely that you have not come across any version controlling tools. Mostly, we see Git being widely used in almost all latest software code bases, while few legacy code bases still use older version controlling software such as SVN (Apache subversion ) or Mercurial.

Has it ever crossed your mind, that why do we use it, or why do we even need it? I mean, there are already so many brain-melting jargons, tools and softwares in software development field, that have already made software development pretty overwhelming and scary for many of us, so, why another layer of trouble?

Let me help you understanding the the origin of “Version Control Systems” and how it saved us “developers”, from eternal dwelling of “my code has been modified! Who changed it?“ to the rabbit hole of “final“, “final_v2“, “latest_final“ directories of deliverable codes, especially in our modern day complex softwares used in wide range of machines. Hi! My name is Abhirup Roy, I am a software engineer with a decade of experience of working on different software code bases and I’ve seen these problems first-hand, repeatedly.

Today’s polished and fancy software development is an outcome of a continuous evolution from a time that predates 1970s, when software development was quite chaotic. Programmers used to store source code on physical punched cards, which they had to manually organize and store in boxes—essentially maintaining a manual versioning system. Later during 1970s, when Unix became popular computer operating system, developers began moving to time-shared computers. With multiple developers working on shared systems and files stored on disks, there was no systematic way to track who changed what, when, or why. Developers would manually copy files to create versions, risking accidental overwrites and data loss.

Let us use a flow diagram to understand this manual source code versioning menace a little better:

The core problems in this approach were:

• No way to track change history

• No accountability for who made which changes

• Manual file copying was error-prone

• Reverting to a previous version was nearly impossible

• Concurrent development caused constant conflicts

A modern day analogy to this situation would be copying source code base to a pen-drive (aka USB flash drive) and sharing with your team of multiple developers, for collaborating and simultaneously working on different components of the software, altogether. In no time, all the above mentioned problems will infest your entire code base and the obvious result will be - “A Total mess”.

In search of solution to this problem, many legendary software engineers have developed different solutions over time, addressing various aspects of what a ‘version controlling tool’ should do.

Era 1: Local Version Control Systems (1972 ~ 1990s)

Marc Rochkind at Bell Laboratories, created “Source Code Control System (SCSS)“ in 1972, the first version control software. Originally written in SNOBOL for an IBM System/370, which Rochkind rewrote in C for UNIX OS in 1973. The first public release came on February 18, 1977.

SCCS introduced revolutionary concepts for its time:

• Delta storage: Instead of storing complete copies of every version, SCCS stored only the differences (deltas) between versions using interleaved delta format, dramatically reducing storage requirements.​

• Version tracking: It maintained a history of all changes with metadata including who made changes, when, and comments (predecessors of today's commit messages)​

• Version numbering: It introduced versioning schemes like 1.1.1 and 1.2.5​

• Simple operations: Users could issue get commands to retrieve versions and delta commands to record changes

However, SCCS had significant limitations. It was local-only (no network support), single-file only (tracked one file at a time, not entire projects), and used a locking mechanism where only one developer could edit a file at a time. Merging multiple developers' changes was impossible.

In 1982, Walter Tichy at Purdue University developed the Revision Control System (RCS), publishing his design in a landmark paper at ICSE'82. RCS maintained SCCS's core concepts but introduced a crucial innovation: reversed deltas. ​Rather than storing the original file plus forward deltas (SCCS's approach), RCS stored the most recent version in full and backward-pointing deltas to older versions. This optimization had profound implications: checking out the latest version became much faster (the most common operation), while retrieving older versions became slower. For typical workflows, this was an excellent trade-off. RCS brought additional improvements:

• Better user experience: Users could specify either the working file or version file, not just version file commands​

• Improved locking mechanism: Unprivileged users could override locks, and lock-breakers received email notification​

• Delta format: Used the more efficient diff format instead of SCCS's interleaved deltas​

RCS remained the dominant local version control system through the 1980s, but it still suffered from SCCS's fundamental limitation: only one developer could work on a file at a time. The field needed a breakthrough that would enable concurrent access.

Era 2: Centralized Version Control Systems (1986 ~ 2004)

Dick Grune developed the Concurrent Versions System (CVS) in July 1986 as a series of shell scripts (later rewritten in C by Brian Berliner in the 1990s). CVS represented a fundamental architectural leap: it was the first version control system to allow multiple developers to work on the same files simultaneously.​

CVS's innovations:

• Client-server architecture: A central server stored the repository; developers checked out copies, made changes locally, and committed back​

• Project-level tracking: Unlike RCS and SCCS (file-level), CVS tracked entire projects and could manage atomic commits across multiple files​

• Network support: Developers could work from different machines over the network​

• Concurrent development: Multiple programmers could edit the same file without blocking each other​

• Merge operations: CVS implemented merge algorithms that combined concurrent changes​

• Branching and tagging: Full support for project branches and version tags​

CVS used a clever approach, it operated as a "front-end to RCS," using RCS's file format internally while adding project-level features. This allowed developers to work independently on private copies and merge changes collaboratively.​

However, CVS had limitations. It struggled with binary file handling, directory operations, and atomic commits (a commit could partially succeed, leaving the repository in an inconsistent state). Additionally, it could only track entire files, not directories as first-class objects.​

Despite these limitations, CVS became the de facto standard for collaborative development by the 1990s.

By the 1990s, the growth of the internet drove demand for better remote repository access. Subversion (SVN) emerged as the spiritual successor to CVS, addressing major limitations:

• Atomic commits: An entire change-set either commits fully or not at all

• Binary file support: True binary versioning without special handling

• Directory versioning: Directories are first-class objects

• Renamed file tracking: Handles file and directory renames properly​

SVN and other centralized systems (Perforce, ClearCase, SourceSafe) dominated enterprise development through the 2000s. Their appeal was clear: a single source of truth, straightforward backup procedures, and centralized access control.​

However, centralized systems had inherent limitations that would become very obvious as the internet enabled distributed teams:

• Network dependency: Developers needed constant server access to commit; offline work was limited

• Merge complexity: Centralizing changes created bottlenecks

• Single point of failure: The central server was critical infrastructure

• Slow operations: Many operations required round-trips to the server​

The stage was set for a revolution.

Era 3: Distributed Version Control Systems (2005 ~ Present Day)

In 2004, the free license for BitKeeper—a proprietary distributed version control system used by the Linux kernel—was revoked. Linus Torvalds, who had led Linux kernel development for over a decade, faced an impossible choice: pay for proprietary software or find an alternative.​

Torvalds investigated existing free version control systems, but none met his stringent requirements. Linux kernel development required extreme performance: developers synchronized with 250+ patch operations simultaneously. With CVS taking 30 seconds per patch operation, synchronization would take hours. Torvalds specified aggressive design goals:​

• Speed: Patching operations must complete in 3 seconds (he later achieved 6.7 patches/second)​

• Distributed workflow: Like BitKeeper, every developer needs a complete repository copy​

• Data integrity: Cryptographic safeguards against accidental or malicious corruption​

• Opposite of CVS: "Take CVS as an example of what not to do; if in doubt, make the exact opposite decision"​

These requirements eliminated every existing system, so Torvalds built his own. Git development began April 3, 2005. Torvalds announced the project on April 6 and achieved self-hosting the next day. By April 29, he had benchmarked Git handling kernel patches at 6.7 patches per second—nearly 200x faster than CVS. On June 16, Git managed the Linux 2.6.12 release.​

Git's Revolutionary Architecture

Git's design broke fundamental assumptions that had guided version control systems for 30 years:​

1. Distributed repositories: Every clone contains the full history. Developers work offline; synchronization happens through peer-to-peer push/pull operations rather than client-server check-in/check-out.​

2. Snapshot-based architecture: Git snapshots entire directory trees, not individual file versions. Unlike RCS/SCCS/CVS (which tracked file identity), Git focuses on content itself. Files can be renamed, split, or merged without losing history.​

3. Content-addressable file system: Each object (commit, tree, blob) is identified by SHA-1 hash of its contents. This provides cryptographic integrity—changing history would require recalculating all subsequent hashes, making corruption obvious.​

4. Three-way merging: Git implements multiple merge strategies, with recursive merging (handling multiple common ancestors) as default, reducing merge conflicts.​

5. Efficient storage: Git uses delta compression (storing changes relative to similar objects) and periodic "garbage collection" to maintain repository efficiency.​

6. Lightweight branching: A branch is merely a reference to a commit, making branch creation trivial. This enables aggressive experimentation.​

These architectural choices made Git fundamentally faster and more suitable for large-scale distributed development than any previous system.​ Other distributed systems like Mercurial, Bazaar and Darcs were also developed as alternative to Git. But Git outpaced them on speed and wide-spread adoption. Git's adoption curve is unprecedented in software development. This acceleration was driven by complementary factors:

• GitHub (2008) - Transformed Git from a command-line tool into a social network for developers. GitHub introduced pull requests, a workflows innovation that simplified code review. By offering free public repositories and paid private repositories, GitHub democratized collaboration. Today, GitHub hosts over 200 million repositories.

• GitLab (2013) - GitLab provided self-hosted Git with integrated CI/CD, DevOps tooling, and enterprise security features. For organizations requiring on-premise infrastructure, GitLab offered a comprehensive DevOps platform.

• BitBucket, Microsoft’s acquisition of GitHub and numerous other platform based on Git, cemented Git’s position as most favored choice for Version Controlling Software.

Modern Git and Git-based platforms like GitHub, GitLab, and BitBucket have turned version control from a necessary burden into a productive, collaborative backbone for software teams. They make everyday work faster, safer, and more automated through branching, pull requests, and deep CI/CD integration.​

How Git Makes Developers’ Lives Easier

• Git’s distributed model gives every developer a full local copy of the repository, so they can commit, diff, and browse history without any network connection. This removes central-server bottlenecks and lets work continue even when VPNs or servers are down.​

• Lightweight branching and merging enable feature branches for every task, letting teams isolate experiments or bug fixes without risking the main production branch. This keeps main stable while still encouraging rapid change and experimentation.​

• Detailed commit history with authors, timestamps, and messages allows easy blame/annotate, audit trails, and precise rollbacks when something goes wrong.​

• Built‑in data integrity (cryptographic hashes for commits and objects) protects history from silent corruption or tampering, which is crucial for large, long‑lived projects.​

• Safer experimentation: Cheap branches plus PR review mean developers can try ideas without fear of breaking production; unwanted experiments can simply be deleted.​

• Better collaboration: Distributed Git plus GitHub/GitLab/BitBucket’s social features (PRs, comments, mentions, issues) let globally distributed teams work effectively across time zones.​

• Higher code quality: Mandatory review, automated testing, and protected branches dramatically reduce bugs reaching users and make it easy to trace when and why a regression appeared.​

• Faster delivery: The combination of feature branches, CI, and CD supports small, frequent releases rather than risky big‑bang deploys, aligning with agile and DevOps best practices.

So, if you are new to software development fraternity, make friendship with Git and Git-based remote repository platforms. On the other hand, if you already have professional experience in software development, having an impressive GitHub profile with real proof of work is much better strategy for networking on X or LinkedIn or applying for Job posts.

If you liked my article, you can subscribe to my blog and get notified, whenever I write a new article on other topics relating to software engineering.

Namaste! Jai Hind!