DEV Community: Amaresh Pati

# Git Adventures --- Part 2: When Git Starts Judging Your Decisions

Amaresh Pati — Thu, 26 Mar 2026 12:32:17 +0000

In Part 1, everything was clean. Repository created. Project initialized. Branches created. Team motivated.

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:

Command	Changes local branch?	Creates merge commit?	Safe to use blindly?
`git fetch`	❌ No	❌ No	✅ Yes
`git merge`	✅ Yes	✅ Maybe	⚠️ Only if branches are synced
`git pull`	✅ Yes	✅ Usually	⚠️ Can surprise you

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:

Situation	Command	Creates new commit?	Safe to push?	Reversible?
Unstaged file mess	`git restore`	❌ No	✅ N/A	❌ Deleted
Staged file mess	`git restore --staged`	❌ No	✅ N/A	✅ Still in working dir
Wrong local commit	`git reset`	❌ No	❌ Rewrites history	✅ Use `git reflog`
Pushed bad commit	`git revert`	✅ Yes	✅ Safe	✅ Fully reversible

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

Problem	Command	Result
View commit history	`git log --oneline`	Shows last commits
See what changed	`git diff`	Shows unstaged changes
See staged changes	`git diff --staged`	Shows changes ready to commit
Compare branches	`git diff main feat/new`	Shows differences
Inspect a commit	`git show <commit-id>`	Shows commit details
Save work temporarily	`git stash -u -m "label"`	Saves including untracked files
Restore saved work	`git stash pop`	Applies last stash
Download remote changes	`git fetch origin`	Safe, doesn't merge
Download + merge	`git pull`	Fetch + merge in one
Undo unstaged changes	`git restore <file>`	Discards edits to file
Unstage changes	`git restore --staged <file>`	Keeps changes, removes from staging
Undo last commit (local)	`git reset HEAD~1`	Moves branch back
Undo last commit (pushed)	`git revert <commit-id>`	Creates undo commit
Undo hard reset	`git reflog`	Shows all HEAD positions

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

Git Adventures --- Part 1: Five Developers, One Repo, and the "It Works on My Machine" Era

Amaresh Pati — Tue, 10 Mar 2026 04:50:00 +0000

Every software project begins the same way.

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 organized.

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 initializes 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 .git, the 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 synchronized.

Chapter 7 --- The Branching Rules

The main 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.

Tools AI Can’t Replace (And I use almost daily)

Amaresh Pati — Tue, 17 Feb 2026 04:50:00 +0000

As developers, we keep discovering tools that quietly make our lives easier.

Not flashy. Not hyped. Just… effective.

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 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

Tool	Problem Solved	Real Impact
DummyJSON	Backend dependency	Faster frontend development
DummyInbox	Email testing clutter	Clean QA, zero inbox pollution
JSON Crack	JSON complexity	Faster debugging & understanding

They don’t replace thinking.

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

👏 Shoutout Where It’s Due

A big shoutout to Ovi

👉 https://github.com/Ovi

For building and maintaining DummyJSON and DummyInbox.

These tools are a great example of developer-first thinking:

simple
reliable
and focused on real problems we face every day

Open-source tools like these quietly power a lot of our workflows — and they deserve more appreciation.

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.

[Boost]

Amaresh Pati — Sat, 07 Feb 2026 06:15:30 +0000

Why I Started Wrapping Everything in React Native?

Amaresh Pati ・ Feb 6

#reactnative #programming #jsx #javascript

Why I Started Wrapping Everything in React Native?

Amaresh Pati — Fri, 06 Feb 2026 04:10:33 +0000

🚀I’ve been working with React Native for about 4 years now, and one thing I’ve learned the hard way is this:
Nothing stays permanent.

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.

DEV Community: Amaresh Pati

# Git Adventures --- Part 2: When Git Starts Judging Your Decisions

Chapter 1 --- The Calm Before the Debugging Storm

Chapter 2 --- Understanding What Actually Changed

Chapter 3 --- Inspecting a Single Decision

Chapter 4 --- The Unexpected Urgent Task

Chapter 5 --- The First Real Merge Conflict

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

Chapter 7 --- Undoing Mistakes Properly

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

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

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

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

The Safety Net: git reflog

Quick Reference Cheat Sheet

End of Part 2

What's Coming in Part 3

Git Adventures --- Part 1: Five Developers, One Repo, and the "It Works on My Machine" Era

Chapter 1 --- The Repo Is Born

Chapter 2 --- The Architect Builds the Foundation

Chapter 3 --- Connecting the Two Worlds

Chapter 4 --- Teaching Git What to Remember

Chapter 5 --- The First Commit

Chapter 6 --- Sharing the Repo With the Team

Chapter 7 --- The Branching Rules

Feature

Bugfix

Hotfix

Chore

Docs

Refactor

Style

Test

Performance

Release

Chapter 8 --- The Feature Crew Begins

End of Part 1

What Happens in Part 2

Tools AI Can’t Replace (And I use almost daily)

DummyJSON — An Instant Backend for Frontend Work

Why it’s genuinely useful

How it helps me

📨 DummyInbox — Clean Email Testing Without Noise

Why I keep using it

Where it fits in my workflow

🔍 JSON Crack — Making Sense of Messy JSON

Features that actually matter

How I use it in real life

🧠 Why These Tools Stick With Me

👏 Shoutout Where It’s Due

Final Note

[Boost]

Why I Started Wrapping Everything in React Native?

Amaresh Pati ・ Feb 6

Why I Started Wrapping Everything in React Native?

The Pattern I Kept Seeing

The Simple Rule I Follow Now

This Slowly Became My Default Style

The Safety Net: `git reflog`