That illusion lasted exactly one day.

Because on Day 2, the team learned an important truth: Writing code is easy. Understanding history is hard.

And Git remembers everything.

Chapter 1 --- The Calm Before the Debugging Storm

Amaresh notices something feels wrong after pulling updates. A feature that worked yesterday is broken. When did this happen?

He opens the timeline:

git log --oneline

Output:

a3f9c2b Add authentication flow
9d1a2e4 Fix validation issue
c81be77 Initial setup

Each commit shows a short hash (abbreviated commit ID) and message.

When you need the full commit ID:

git log

Or to just grab HEAD's full ID:

git rev-parse HEAD

Output:

a3f9c2b7d8e9f0a1b2c3d4e5f6g7h8i9

Pro tip: Use git log --oneline -n 20 to see only the last 20 commits. Saves scrolling through months of history.

The gotcha: git log shows commits in reverse chronological order (newest first). If you're looking for when something broke, scroll down, not up.

Commit IDs are your time machine. They allow precise navigation through Git history—and they're immutable. The same commit ID always points to the exact same code, forever.

Chapter 2 --- Understanding What Actually Changed

Amaresh needs to see exactly what was changed. Not just which files, but which lines.

git diff

Output:

diff --git a/auth.js b/auth.js
index 1a2b3c4..5d6e7f8 100644
--- a/auth.js
+++ b/auth.js
@@ -12,7 +12,7 @@
  function validateToken(token) {
-   if (token.length < 32) {
+   if (token.length < 16) {
      return false;
    }

Git highlights removed lines in red (with -) and added lines in green (with +).

Compare two branches:

git diff main feat/authentication

This shows all changes in feat/authentication that aren't in main.

Compare two commits:

git diff a3f9c2b 9d1a2e4

See only filenames (not the code):

git diff --name-only main feat/authentication

See file statistics:

git diff --stat main feat/authentication

Output:

auth.js     | 15 ++++++++++++---
utils.js    |  8 ++------
 2 files changed, 14 insertions(+), 9 deletions(-)

The gotcha: git diff with no arguments shows unstaged changes only. If you've already run git add, you won't see those changes. Use git diff --staged to see staged changes.

Chapter 3 --- Inspecting a Single Decision

Johnny broke something three commits ago. Now Amaresh needs to see exactly what that commit changed.

git show a3f9c2b

Output:

commit a3f9c2b7d8e9f0a1b2c3d4e5f6g7h8i9
Author: Johnny <johnny@company.com>
Date:   Wed Mar 24 14:32:15 2026 +0530

    Add authentication flow

diff --git a/auth.js b/auth.js
new file mode 100644
index 0000000..a1b2c3d
--- /dev/null
+++ b/auth.js
@@ -0,0 +1,45 @@
+function authenticate(user, password) {
...

git show displays:

• Author — who made the change

• Date — when it was committed

• Message — the commit description

• Full diff — every line added/removed

See just the commit message:

git show a3f9c2b --format=fuller

Use with current HEAD:

git show HEAD

This is your bug detective tool. When you find a broken line, you can track exactly when it was added and by whom.

The gotcha: If a commit only renamed a file without changing it, git show will say "similarity index 100%" but show no actual changes. The file content is identical.

Chapter 4 --- The Unexpected Urgent Task

Danny has been working on a feature for hours. Code is half-written, tests are incomplete. Then a critical production bug appears, and he must switch branches immediately.

He can't commit incomplete work (it breaks the build). He can't lose his changes. So he uses:

git stash

This saves all changes to a temporary location and resets the working directory to the last commit.

git checkout hotfix/critical-bug
# Fix the bug, commit, merge back to main
git checkout feat/incomplete-feature

Now he gets his incomplete work back:

git stash pop

But there's a problem: He had created a new file (utils.js) that hadn't been staged. After stashing and popping, the file is gone.

That's because git stash by default only saves tracked files (files Git already knows about). New files are left behind.

The solution:

git stash -u

The -u (or --include-untracked) flag tells Git to stash everything, including brand new files.

Better yet, use this to be safe:

git stash -u -m "WIP: authentication feature with new utils"

The -m flag lets you label the stash so you remember what's in it.

View all stashes:

git stash list

Output:

stash@{0}: WIP: authentication feature with new utils
stash@{1}: WIP: fixing typo in validator
stash@{2}: On main: saving work

Pop a specific stash:

git stash pop stash@{1}

Delete a stash without popping:

git stash drop stash@{0}

Clear all stashes (⚠️ dangerous):

git stash clear

The gotcha: git stash pop removes the stash after applying it. If the pop fails (merge conflict), the stash stays safe. But if it succeeds and you later realize you needed it, it's gone. Use git stash apply instead if you want to keep the stash around.

Chapter 5 --- The First Real Merge Conflict

Johnny finishes his service-layer feature. Ronaldo finishes his database optimization feature. Both edited the same file. Johnny tries to merge Ronaldo's branch:

git merge feat/service-layer

Git responds:

Auto-merging api.js
CONFLICT (content): Merge conflict in api.js
Automatic merge failed; fix conflicts and then commit the result.

He opens api.js and sees:

function handleRequest(req, res) {
<<<<<<< HEAD
  // Ronaldo's code (database optimization)
  const data = db.query(req.id);
  res.send(data);
=======
  // Johnny's code (service layer)
  const service = new Service();
  const data = service.fetch(req.id);
  res.send(data);
>>>>>>> feat/service-layer
}

The conflict markers show:

• <<<<<<< HEAD — start of current branch (what you have now)

• ======= — divider

• >>>>>>> feat/service-layer — end of incoming branch (what you're merging in)

Johnny must decide: Keep Ronaldo's code? Keep his own? Use both?

He decides to use his service layer but call the optimized query:

function handleRequest(req, res) {
  const service = new Service();
  const data = service.fetch(req.id); // Johnny's code
  // Ronaldo's optimization is now inside service.fetch()
  res.send(data);
}

Now resolve the conflict:

git add api.js
git commit -m "Merge feat/service-layer: resolve conflict in api.js"

Tools to help with conflicts:

# See which files have conflicts
git diff --name-only --diff-filter=U

# Use a visual merge tool (if configured)
git mergetool

Abort a merge if you're not ready:

git merge --abort

The gotcha: Merge conflicts are not errors—they're Git asking you to make a decision. A merge with zero conflicts often means someone's code got silently overwritten. Conflicts are actually good; they force you to think.

Chapter 6 --- Fetch vs Pull vs Merge (The Confusion Explained)

Many developers use these terms interchangeably. They're not.

git fetch — Downloads changes from remote, but doesn't integrate them:

git fetch origin

This updates your local tracking branches (origin/main, origin/feat/something) but leaves your local main branch untouched.

git merge — Combines histories:

git merge origin/main

This integrates the remote changes into your current branch.

git pull — Fetch + merge in one command:

git pull origin main

Equivalent to:

git fetch origin
git merge origin/main

Why does this matter?

The professional workflow is:

git fetch origin          # Download changes
git log main origin/main  # Inspect what changed
git merge origin/main     # Merge when ready

Why? Because git pull can silently create merge commits you didn't expect. Fetching first lets you review changes before integrating them.

Comparison table:

The gotcha: git pull can create a merge commit automatically. If you're trying to keep a clean history, this is annoying. Use git pull --rebase to rebase instead of merge (we'll cover rebase in Part 3).

Chapter 7 --- Undoing Mistakes Properly

Mistakes happen. Git gives you three different ways to undo, and they each do something different.

Mistake Type 1: "I edited a file but haven't staged it"

Amaresh edited config.js but realizes it's wrong. He hasn't run git add yet.

git restore config.js

This overwrites config.js with the version from the last commit. Changes are gone.

Old syntax (still works):

git checkout config.js

Mistake Type 2: "I staged changes I shouldn't have"

Amaresh ran git add . and included config.js accidentally. He hasn't committed yet.

git restore --staged config.js

This unstages the file. The file still exists in your working directory with all changes intact—only the staging is removed.

Undo all staged changes:

git restore --staged .

Mistake Type 3: "I committed something wrong but haven't pushed"

Johnny committed buggy code. It's in his local history but not on GitHub yet.

git reset HEAD~1

This moves the branch pointer back one commit. The buggy commit disappears from history. But the files are still in your working directory with changes intact.

# Edit the files, fix the bug
git add .
git commit -m "Fixed version of that commit"

The variants:

git reset --soft HEAD~1   # Undo commit, keep changes staged
git reset --mixed HEAD~1  # Undo commit, keep changes unstaged (default)
git reset --hard HEAD~1   # Undo commit, DISCARD all changes (⚠️ dangerous)

The gotcha: git reset --hard is permanent. Your code is deleted. If you haven't pushed, you can use git reflog to recover, but it's nerve-wracking. Default to --mixed or --soft.

Mistake Type 4: "I committed bad code that's already pushed"

Ronaldo pushed a commit that broke production. He can't just git reset because others have already pulled his changes. Rewriting history would break their local repos.

git revert a3f9c2b

This creates a new commit that undoes the changes from commit a3f9c2b. Git history stays intact. Everyone can pull the revert safely.

Output:

[main 7f8e9d0] Revert "Add broken authentication"
 1 file changed, 2 deletions(-)

Now the repo is fixed, and history shows exactly what happened.

Compare the three approaches:

The Safety Net: git reflog

Here's the command nobody tells you about until you need it.

Amaresh ran git reset --hard and deleted code he wanted. Is it gone forever?

git reflog

Output:

a3f9c2b HEAD@{0}: reset: moving to HEAD~1
9d1a2e4 HEAD@{1}: commit: Add authentication flow
c81be77 HEAD@{2}: commit: Initial setup

The reflog shows every place HEAD has been. He can recover:

git reset --hard HEAD@{1}

The safety net catches you. Use this when you panic after a hard reset.

Quick Reference Cheat Sheet

By the end of Day 2, the team realized something important:

Git doesn't judge you for making mistakes. It judges you for not knowing how to recover from them.

Master these commands, and you'll never panic:

• git log + git show — understand what happened

• git diff — see exactly what changed

• git stash — escape from immediate problems

• git restore / git reset / git revert — fix them the right way

• git reflog — panic button

End of Part 2

The team learned:

• git log --oneline — time machine for commits

• git diff — see changes precisely

• git show — inspect a single commit

• git stash -u — save incomplete work

• Merge conflicts — human decisions required

• git fetch vs git pull — when to use which

• git restore vs git reset vs git revert — right tool for the job

• git reflog — the safety net

What's Coming in Part 3

• Rebase — rewriting history (safely)

• Interactive rebase — rearranging commits

• Cherry-pick — copying specific commits

• Tagging — marking important versions

• Rebasing vs Merging — the great Git debate

Someone says, "Let's build something amazing."

Ten minutes later, someone asks:

"Wait... who created the Git repo?"

This is the story of a five-person development team starting their first project together.

Meet the team.

Virat --- The Repo Master Responsible for repositories and access control.

Amaresh --- The Architect designs the project structure and keeps the codebase organised.

Johnny, Danny, Ronaldo --- The Feature Crew: Three developers who will build features, write code, and occasionally break things.

Today is Day 1.

And the project begins with the most important step in any software project.

Creating the repository.

Chapter 1 --- The Repo Is Born

Virat opens his terminal and announces that the project officially begins.

mkdir project-hyperdrive
cd project-hyperdrive

Now he initialises Git.

git init

Git responds:

Initialized empty Git repository

Behind the scenes, something important just happened.

Git created a hidden folder called:

.git

This folder stores everything Git needs:

• commit history

• branches

• logs

• references

• repository metadata

Without .gitthe folder is just a normal directory.

With .git It becomes a version-controlled project.

Chapter 2 --- The Architect Builds the Foundation

Virat turns to Amaresh.

The repository exists now, but a repository without files is like a city without buildings.

Amaresh prepares the initial project structure on his machine.

He checks what Git sees.

git status

Output:

Untracked files:
README.md
src/
config/

Git sees the files but does not track them automatically.

Developers must tell Git which files should be tracked.

Chapter 3 --- Connecting the Two Worlds

Virat created the repository on his machine, and Amaresh prepared the project on his laptop.

Johnny asks:

"How are we working in the same repository?"

Virat explains.

Local Repository → developer machines
Remote Repository → shared server

Virat connects his repository to the remote server.

git remote add origin https://company-repo/project.git
git push -u origin main

Amaresh connects his machine to the same repository.

git remote add origin https://company-repo/project.git
git pull origin main

Now both machines share the same Git history.

Chapter 4 --- Teaching Git What to Remember

Amaresh stages the project files.

git add .

The dot (.) means add everything inside the current directory.

Git workflow:

Working Directory → Staging Area → Commit History

Staging allows developers to choose which files should go into the next commit.

Chapter 5 --- The First Commit

Amaresh creates the first commit.

git commit -m "Initial project setup"

A commit is a snapshot of the project at a specific moment.

Each commit records:

• changes

• author

• time

• commit message

Chapter 6 --- Sharing the Repo With the Team

Virat grants repository access to the team.

Johnny clones the repository.

git clone https://company-repo/project.git

Danny checks the status.

git status

Output:

On branch main
Your branch is up to date with origin/main

Everyone is synchronised.

Chapter 7 --- The Branching Rules

The main The branch must always remain stable.

Developers create branches for their work.

Feature

feat/login-system
feat/payment-module

Bugfix

bugfix/login-validation
bugfix/crash-on-start

Hotfix

hotfix/security-patch
hotfix/payment-crash

Chore

chore/update-dependencies

Docs

docs/setup-guide

Refactor

refactor/auth-module

Style

style/code-formatting

Test

test/auth-tests

Performance

perf/query-optimization

Release

release/v1.0

Workflow:

Create branch → Commit → Push → Pull Request → Review → Merge

Chapter 8 --- The Feature Crew Begins

Amaresh assigns tasks.

Johnny:

git checkout -b feat/authentication

Danny:

git checkout -b feat/profile-system

Ronaldo:

git checkout -b feat/service-integration

Three developers.

Three branches.

One repository.

And somewhere in the future...

A merge conflict is waiting.

End of Part 1

What the team learned:

• git init

• git status

• git add

• git commit

• git remote

• git push

• git clone

• git branch

Branch naming examples:

feat/
bugfix/
hotfix/
docs/
chore/
refactor/
style/
test/
perf/
release/

What Happens in Part 2

In the next part, the team will learn:

• PR creation

• git log

• git diff

• git show

• git stash

• resolving merge conflicts

Follow the series for Part 2.

These are three tools I keep coming back to because they remove friction from my workflow.
They save time, reduce mental load, and let me focus on building features instead of fighting setup, data, or formats.

DummyJSON — An Instant Backend for Frontend Work

🔗 https://dummyjson.com

When I start working on a new feature, backend readiness is often the bottleneck.
DummyJSON removes that problem entirely.

It gives you custom & ready-to-use REST APIs with realistic data — users, products, posts, todos, comments, and more — without any setup.

Why it’s genuinely useful

• Create custom APIs using your own JSON
• Ready endpoints like /products, /users, /todos, /posts
• Full HTTP support: GET, POST, PUT, PATCH, DELETE
• Pagination, search, and filtering built in
• Zero setup. Zero configuration.

How it helps me

• I build UI and business logic without waiting on backend completion
• I can test real-world scenarios like loading states and empty responses
• No need to maintain mock servers or fake data generators

Instead of guessing how data might look, I work with something close to production from day one.

📨 DummyInbox — Clean Email Testing Without Noise

🔗 https://dummyinbox.com

Testing email-based flows using your real inbox gets messy fast.
DummyInbox fixes this with the simplest possible approach.

You get disposable email addresses instantly — no signup, no login, no tracking.

Why I keep using it

• Instant temporary email addresses
• Auto-expiring inboxes
• No spam in personal or work email
• Unlimited usage, completely free

Where it fits in my workflow

• Testing signup and onboarding flows
• Verifying OTPs and confirmation emails
• QA testing notification and alert emails

It does one job — and does it really well.

🔍 JSON Crack — Making Sense of Messy JSON

🔗 https://jsoncrack.com/editor

If you work with APIs, you will deal with large, deeply nested JSON responses.
JSON Crack turns that chaos into clarity.

Paste your JSON and instantly get a visual tree or graph of the structure.

Features that actually matter

• Interactive visualization of JSON structures
• Supports JSON, YAML, CSV, XML, TOML
• Built-in formatter and validator
• Easy format conversion
• Export visuals for documentation or sharing

How I use it in real life

• Understand complex API responses copied from Postman
• Debug unexpected nested fields quickly
• Explain payload structures to teammates without long explanations

Scrolling raw JSON is painful.
Visualizing it saves time and mental energy.

🧠 Why These Tools Stick With Me

They don’t replace thinking.
They remove unnecessary effort — and that’s exactly what good tools should do.

👏 Shoutout

A big shoutout to Ovi
👉 https://github.com/Ovi

For building and maintaining DummyJSON and DummyInbox.

Final Note

I’ve tried many productivity tools.
Most don’t survive daily usage.

These three did — because they solve real problems I face while building products.
No hype. Just utility.

If you’re a frontend, mobile, or full-stack developer, chances are these tools will quietly improve your workflow too.

Libraries get deprecated.
Best practices change.
Things that were “recommended” last year suddenly feel wrong today.

At some point, I started asking myself:

Why am I fixing the same problem again and again, just because a library changed?🤔

The Pattern I Kept Seeing

Let’s be honest — React Native apps don’t die quickly.
They live for years.

But during that time:

• FlatList starts struggling with performance

• FlashList shows up and becomes the new standard

• SafeAreaView from react-native is no longer enough

• We move to react-native-safe-area-context

And suddenly you’re touching dozens of files for what is essentially one decision change.

That’s when I realised —
The mistake was never the library choice; it was how tightly my app depended on it.

The Simple Rule I Follow Now

• Never use core or third-party components directly across the app.

• Wrap them once. Own them.

I started creating a top layer of base components.

Example 1: Lists (FlatList → FlashList)

What I stopped doing
Using FlatList directly everywhere:

import { FlatList } from 'react-native';

Because I already know how this story ends.

What I do instead: AppFlatList

// AppFlatList.tsx
import React from 'react';
import { FlatList, FlatListProps } from 'react-native';

export function AppFlatList<T>(props: FlatListProps<T>) {
  return (
    <FlatList
      {...props}
      removeClippedSubviews
      windowSize={5}
      initialNumToRender={10}
    />
  );
}

Usage stays simple:

<AppFlatList
  data={data}
  renderItem={renderItem}
  keyExtractor={(item) => item.id}
/>

Now, when performance becomes an issue (and it will), I don’t panic.

Later… switching to FlashList

// AppFlatList.tsx
import { FlashList, FlashListProps } from '@shopify/flash-list';

export function AppFlatList<T>(props: FlashListProps<T>) {
  return <FlashList {...props} estimatedItemSize={60} />;
}

That’s it.

No screen changes.
No refactor weekends.
No stress.

Example 2: Base Component Deprecation (SafeAreaView)
This one hit me multiple times.

Earlier we all used:

import { SafeAreaView } from 'react-native';

Later, we were told:

“Use react-native-safe-area-context instead.”

Now imagine SafeAreaView used everywhere.

Painful, right?

// AppSafeAreaView.tsx
import React from 'react';
import { SafeAreaView } from 'react-native-safe-area-context';

export function AppSafeAreaView({ children, style }) {
  return (
    <SafeAreaView style={[{ flex: 1 }, style]}>
      {children}
    </SafeAreaView>
  );
}

Usage:

<AppSafeAreaView>
  <HomeScreen />
</AppSafeAreaView>

Now I don’t care:

• if API changes

• if padding logic changes

• if Android/iOS behavior differs later

• I’ve isolated it.

This Slowly Became My Default Style

Now I do this for almost everything:

• AppText → font scaling, typography updates

• AppButton → design system changes

• AppInput → validation, focus handling

• AppImage → caching, placeholders

• AppPressable → analytics hooks later

• Every time I hesitate and think

“Should I just use this directly?”

I remember how many times I’ve regretted that decision.

Why This Matters (Real Talk)
React Native evolves fast.
Your app doesn’t.

So either:

• You chase changes every year
  or

• You design your app to absorb them calmly

Wrapping components doesn’t slow you down.
Refactoring later does.

Final Thought
This isn’t about over-engineering.
It’s about respecting the fact that change is guaranteed.

I don’t wrap components because I expect problems today.
I wrap them because I know future-me will be tired.

And honestly?
Future-me deserves better.