DEV Community: Shuvo

Before AI we had ...

Shuvo — Fri, 22 May 2026 04:12:37 +0000

Nowadays you will hear a lot of people saying Why should I hire a software developer when I can vibecode it my self with about $100 worth of AI tools?

Well they aren't wrong about that!

But getting an app made and running was never the hard part. Before AI or vibe coding we had platforms like Fiverr/UpWork where people could just pay a third world country developer $50-$100 to build them their app.

So getting a working APP or at least MVP was never really very hard or expensive rather its the distribution part that kills 99% of the apps.

And for handling complex apps or codebases cheap developers were not reliable then, AI tools are not reliable now!

Frontend rate limiting can save you $10,000

Shuvo — Thu, 21 May 2026 04:04:07 +0000

Fastest Requests Are the Ones You Never Make

While backend rate limiting is absolutely crucial, it comes at a cost.

For backend rate limiting, we usually store a user's IP and request timestamps in memory or a Redis database. If your app has millions of users, you end up storing a lot of data in memory or a database — and that can get expensive fast.

But what if we block requests before they ever leave the browser/client? By handling rate limiting on the client side, we can save a significant number of unnecessary request and read/write operations on the backend. Depending on how many users your app has, this can translate to anywhere between hundreds to thousands of dollars saved per year.

1: Basic frontend rate limiter example:

// utils/rate-limiter.ts

const MAX_REQUESTS = 50;           // Maximum number of requests allowed
const TIME_WINDOW = 60 * 1000;    // Time window in milliseconds (1 minute)

// Store timestamps of recent requests
let requestTimestamps: number[] = [];

// Check if a new request is within the allowed limit
function canMakeRequest(): boolean {
    const currentTime = Date.now();

    // Remove timestamps that have fallen outside the time window
    requestTimestamps = requestTimestamps.filter(
        timestamp => currentTime - timestamp < TIME_WINDOW
    );

    return requestTimestamps.length < MAX_REQUESTS;
}

// Drop-in fetch wrapper with rate limiting
function $fetch(url: string, options?: RequestInit): Promise<Response> {
    if (!canMakeRequest()) {
        return Promise.reject(new Error('Rate limit exceeded. Please try again later.'));
    }

    requestTimestamps.push(Date.now());
    return fetch(url, options);
}

export default $fetch;

2. Better rate limiter with cooldown time and localstorage implementation so user can't just reset limit by refreshing the page

// Front end rate limiter
// Max number of requests allowed per time window
const MAX_REQUESTS = 50; // Maximum number of requests allowed
const TIME_WINDOW = 60 * 1000; // Time window in milliseconds (e.g., 1 minute)
const COOLDOWN_TIME = 30 * 1000; // Time to wait after hitting the rate limit before requests are allowed again

// localStorage keys for persisting state across page refreshes
const STORAGE_KEY_TIMESTAMPS = 'rate_limiter_timestamps';
const STORAGE_KEY_COOLDOWN = 'rate_limiter_cooldown_until';

// --- localStorage helpers ---

// Load request timestamps from localStorage, falling back to an empty array
function loadTimestamps(): number[] {
    try {
        const stored = localStorage.getItem(STORAGE_KEY_TIMESTAMPS);
        return stored ? JSON.parse(stored) : [];
    } catch {
        return [];
    }
}

// Persist the current timestamps array to localStorage
function saveTimestamps(timestamps: number[]): void {
    try {
        localStorage.setItem(STORAGE_KEY_TIMESTAMPS, JSON.stringify(timestamps));
    } catch {
        // Silently fail if localStorage is unavailable (e.g. private browsing restrictions)
    }
}

// Load the cooldown expiry timestamp (ms since epoch), or 0 if none is set
function loadCooldownUntil(): number {
    try {
        return Number(localStorage.getItem(STORAGE_KEY_COOLDOWN) ?? 0);
    } catch {
        return 0;
    }
}

// Persist the cooldown expiry timestamp to localStorage
function saveCooldownUntil(until: number): void {
    try {
        localStorage.setItem(STORAGE_KEY_COOLDOWN, String(until));
    } catch {
        // Silently fail if localStorage is unavailable
    }
}

// --- Core rate-limit logic ---

// Function to check if a request can be made
function canMakeRequest(): boolean {
    const currentTime = Date.now();

    // If an active cooldown exists, block all requests until it expires
    const cooldownUntil = loadCooldownUntil();
    if (cooldownUntil && currentTime < cooldownUntil) {
        return false;
    }

    // Load persisted timestamps so a page refresh doesn't reset the counter
    let requestTimestamps = loadTimestamps();

    // Remove timestamps that are outside the time window
    requestTimestamps = requestTimestamps.filter(
        timestamp => currentTime - timestamp < TIME_WINDOW
    );

    // Persist the cleaned-up timestamps
    saveTimestamps(requestTimestamps);

    // Check if the number of requests in the time window is less than the maximum allowed
    return requestTimestamps.length < MAX_REQUESTS;
}

// Function to make a request
function $fetch(url: string, options?: RequestInit): Promise<Response> {
    if (!canMakeRequest()) {
        // Inform the caller how long (in seconds) they need to wait
        const remaining = Math.ceil((loadCooldownUntil() - Date.now()) / 1000);
        return Promise.reject(
            new Error(`Rate limit exceeded. Please try again in ${remaining}s.`)
        );
    }

    const currentTime = Date.now();

    // Load, update, and persist timestamps before making the request
    const requestTimestamps = loadTimestamps();
    requestTimestamps.push(currentTime);
    saveTimestamps(requestTimestamps);

    // If this request tips us over the limit, start a cooldown period.
    // The cooldown begins NOW and lasts COOLDOWN_TIME ms, after which
    // canMakeRequest() will unblock and the sliding window will have cleared.
    if (requestTimestamps.length >= MAX_REQUESTS) {
        saveCooldownUntil(currentTime + COOLDOWN_TIME);
    }

    // Make the actual fetch request
    return fetch(url, options);
}

export { $fetch };

Whenever you need to make a request to the backend, just use $fetch instead of the native fetch:

// example usage
import $fetch from 'utils/rate-limiter';

try {
    const data = await $fetch('/api/get-data', {
        method: 'POST',
        body: JSON.stringify({ key: 'value' })
    });
} catch (error) {
    console.error(error.message);
}

⚠️ Warning: This will prevent the vast majority of users from flooding your backend, but a determined minority and AI bots may attempt to bypass client-side checks entirely. Backend rate limiting must still be in place as your true line of defense. Think of frontend rate limiting as an optimization layer, not a security layer.

When to Use Frontend Rate Limiting

Your app has a high volume of users and you want to reduce unnecessary backend load
The endpoint being called is expensive (e.g., hits a third-party API, runs a heavy DB query)
You want to improve UX by giving users instant feedback instead of waiting for a backend 429 response
You want to reduce cloud costs on services that charge per request or per DB operation

When Not to Use Frontend Rate Limiting

As a replacement for backend rate limiting — it is never a substitute
For protecting sensitive or security-critical endpoints (authentication, payments, etc.)
When your users are primarily API consumers or developers who interact directly with your backend
When the client environment is untrusted (e.g., mobile apps that can be reverse-engineered or patched)
When accurate rate limiting is a hard requirement — client-side state can be reset simply by refreshing the page

Your trycatch sucks - lets fix it

Shuvo — Thu, 21 May 2026 03:19:50 +0000

You're not handling errors. You're hiding them.

Every app crashes. Every API fails. Every database hiccups at 2am on a Friday.
The difference between a good dev and a great one? What happens next.

Let's roast your error handling — then make it legendary.

🤦 Level 0: The "Trust Me Bro" Dev

No try/catch at all. Just vibes.

const data = await fetchUserData(userId);
console.log(data.profile.name); // 💥 TypeError: Cannot read properties of undefined

The crime: One bad response nukes the entire app. Users see a white screen. You get a 3am Slack ping.

🐣 Level 1: The Junior — "I Googled try/catch"

try {
  const data = await fetchUserData(userId);
  setUser(data);
} catch (err) {
  console.log(err); // 👈 and... that's it. shipped.
}

What's wrong here?

console.log in production helps nobody — users still see a broken UI
No distinction between a 404 and a 500 — every error is treated the same
The error disappears into the void (or a DevTools tab nobody has open)
err might be null, a string, or an Error object — you're not checking

The mindset: "At least it won't crash." — Yeah, it just silently breaks instead. Cool.

📈 Level 2: The Mid-Level — "I've Been Burned Before"

Now we're thinking. You've seen production fires. You have trust issues with APIs. Good.

2a — Typed errors, real messages

try {
  const data = await fetchUserData(userId);
  setUser(data);
} catch (err) {
  if (err instanceof NetworkError) {
    showToast("Connection lost. Check your internet.", "warning");
  } else if (err.status === 404) {
    showToast("User not found.", "error");
  } else {
    showToast("Something went wrong. We're on it.", "error");
    logger.error("[fetchUserData]", { userId, err }); // 👈 goes to Sentry/Datadog
  }
}

✅ Users get useful feedback, not a frozen screen
✅ Engineers get structured logs, not a haystack of console.logs

2b — Undo previous operations (the "atomic mindset")

Imagine you're updating a user's profile and their avatar. Step 1 succeeds. Step 2 fails.
Congrats — your user now has a corrupted half-state.

let previousProfile = null;

try {
  previousProfile = await getProfile(userId); // snapshot
  await updateProfile(userId, newProfileData); // step 1
  await uploadAvatar(userId, newAvatar);        // step 2 💥 fails here
} catch (err) {
  logger.error("Profile update failed", { err });

  // ↩️ Roll back step 1 since step 2 failed
  if (previousProfile) {
    await updateProfile(userId, previousProfile);
  }

  showToast("Update failed. Your profile has been restored.", "warning");
}

✅ Users never see broken half-state
✅ Rollback is explicit, not accidental

2c — Wrap it in a clean utility (stop repeating yourself)

Tired of writing try/catch 50 times? Make a helper:

// utils/tryCatch.js
export async function tryCatch(fn, fallback = null) {
  try {
    const result = await fn();
    return [result, null];
  } catch (err) {
    return [fallback, err];
  }
}

// Usage — clean, flat, readable
const [user, err] = await tryCatch(() => fetchUserData(userId));

if (err) {
  showToast("Couldn't load user.", "error");
  return;
}

setUser(user);

✅ No more deeply nested try/catch pyramids
✅ Forces you to handle the error at call site — can't ignore it

🧠 Level 3: The Senior — "I've Seen Things"

You don't just catch errors. You anticipate them. You build systems that heal themselves.

3a — Retry queue with exponential backoff

Networks are flaky. Don't give up on the first failure.

async function fetchWithRetry(fn, { retries = 3, delay = 500 } = {}) {
  for (let attempt = 1; attempt <= retries; attempt++) {
    try {
      return await fn();
    } catch (err) {
      const isLast = attempt === retries;
      const isRetryable = err.status >= 500 || err instanceof NetworkError;

      if (isLast || !isRetryable) throw err; // don't retry 401s or 404s

      const backoff = delay * 2 ** (attempt - 1); // 500ms → 1s → 2s
      logger.warn(`Attempt ${attempt} failed. Retrying in ${backoff}ms...`);
      await sleep(backoff);
    }
  }
}

// Usage
const data = await fetchWithRetry(() => fetchUserData(userId));

✅ Temporary blips are invisible to users
✅ Smart: retries server errors, not client errors (no point retrying a 401)

3b — Circuit breaker (stop hammering a dead service)

A retry queue is great — unless the whole service is down. Then you're just DDoS-ing a corpse.

class CircuitBreaker {
  constructor(threshold = 5, timeout = 30_000) {
    this.failures = 0;
    this.threshold = threshold;
    this.timeout = timeout;
    this.state = "CLOSED"; // CLOSED = healthy, OPEN = tripped, HALF_OPEN = testing
    this.nextAttempt = Date.now();
  }

  async call(fn) {
    if (this.state === "OPEN") {
      if (Date.now() < this.nextAttempt) {
        throw new Error("Circuit open — service unavailable");
      }
      this.state = "HALF_OPEN";
    }

    try {
      const result = await fn();
      this.reset();
      return result;
    } catch (err) {
      this.recordFailure();
      throw err;
    }
  }

  recordFailure() {
    this.failures++;
    if (this.failures >= this.threshold) {
      this.state = "OPEN";
      this.nextAttempt = Date.now() + this.timeout;
      logger.error("🔴 Circuit breaker TRIPPED");
    }
  }

  reset() {
    this.failures = 0;
    this.state = "CLOSED";
  }
}

// Usage
const userServiceBreaker = new CircuitBreaker();
const data = await userServiceBreaker.call(() => fetchUserData(userId));

✅ Failing fast is kind — users get an error immediately, not after 10s of retrying
✅ Gives the downstream service a breather to recover

3c — Structured error classes (errors that mean something)

Stop throwing raw strings or generic Errors. Give your errors context.

class AppError extends Error {
  constructor(message, { code, statusCode = 500, context = {}, retryable = false } = {}) {
    super(message);
    this.name = "AppError";
    this.code = code;
    this.statusCode = statusCode;
    this.context = context;
    this.retryable = retryable;
    this.timestamp = new Date().toISOString();
  }
}

// Subclass for specificity
class AuthError extends AppError {
  constructor(message, context) {
    super(message, { code: "AUTH_ERROR", statusCode: 401, context, retryable: false });
  }
}

class ServiceUnavailableError extends AppError {
  constructor(service, context) {
    super(`${service} is unavailable`, { code: "SERVICE_DOWN", statusCode: 503, context, retryable: true });
  }
}

// Throwing
throw new ServiceUnavailableError("UserService", { userId, attempt: 3 });

// Catching
catch (err) {
  if (err instanceof AuthError) {
    redirectToLogin();
  } else if (err instanceof AppError && err.retryable) {
    retryQueue.add(err);
  } else {
    logger.error(err.code, err.context);
    showToast("Unexpected error. Engineers notified.");
  }
}

✅ Catch blocks can make decisions, not just log and pray
✅ Every error carries its own context — no more guessing what happened

🗺️ The Full Picture

What you do	Junior	Mid	Senior
Catch errors	✅	✅	✅
Inform the user	❌	✅	✅
Send to a logger	❌	✅	✅
Typed/structured errors	❌	⚠️ partial	✅
Rollback on failure	❌	✅	✅
Retry transient errors	❌	❌	✅
Circuit breaker	❌	❌	✅
Errors are self-describing	❌	❌	✅

✅ The Golden Rules

Never swallow errors silently. A hidden bug is a time bomb.
Always tell the user something. Frozen UI is worse than an error message.
Log with context, not just a message — what failed, who triggered it, when.
Not all errors are equal — 404 ≠ 500 ≠ NetworkError. Handle them differently.
Retryable ≠ always retry — client errors (4xx) should fail fast.
Leave the system in a valid state. Roll back or compensate when operations are partial.
Your catch block is business logic — treat it that way.

"The mark of a great engineer isn't writing code that never fails.

It's writing code that fails gracefully."

Now go fix your try/catches. 🛠️

I Built a Fully Automated YouTube Channel That Uploads Every Day - Without Touching It

Shuvo — Wed, 20 May 2026 04:57:27 +0000

Every morning, a video goes live on my YouTube channel. I didn't film it. I didn't edit it. My computer did all of it while I slept.

Here's the story of how I built Progress Bar of the Year - a fully automated YouTube Shorts channel that posts a daily update on how much of the current year has passed - and the surprisingly elegant tech stack behind it.

The Idea: Simple, But Strangely Satisfying

The premise couldn't be simpler: every day, a short video goes up showing what percentage of the year has elapsed, paired with a fun historical fact about something that happened on this same day in a previous year.

That's it.

But there's something almost meditative about watching the year tick forward - and something genuinely cool about a channel that runs itself. No burnout, no filming schedule, no editor. Just code, running quietly on a small computer in the corner.

The Tech Stack at a Glance

Layer	Tool
Core logic	JavaScript / TypeScript
Historical facts	Google Gemini API
Video generation	Remotion
Upload	YouTube Data API v3
Automation	Bash + crontab

Let's break down each piece.

Step 1: The Math - How Much of the Year Has Passed?

What it does: Calculates today's date, the total days in the current year, and the percentage of the year that's gone by.

How it works: This is pure JavaScript - no libraries needed. The logic boils down to three things:

const now = new Date();
const startOfYear = new Date(now.getFullYear(), 0, 1);
const endOfYear = new Date(now.getFullYear() + 1, 0, 1);

const elapsed = now - startOfYear;
const total = endOfYear - startOfYear;
const percentage = ((elapsed / total) * 100).toFixed(2);

It also accounts for leap years automatically, since endOfYear - startOfYear will naturally be 366 days in a leap year.

Why this approach: JavaScript's Date object handles all the heavy lifting. There's no edge case to manually code - the language figures out whether it's February 28th or 29th, whether we're in a leap year, all of it. Simple and bulletproof.

Output: A number like 38.21 - meaning 38.21% of 2026 has already passed.

Step 2: The History Hook - Google Gemini API

What it does: Fetches a genuinely interesting historical event that happened on this exact calendar day in a previous year.

Why AI instead of a static database? A hardcoded database of historical facts would work - but it would be finite, brittle, and boring to maintain. The Gemini API gives us:

An effectively unlimited and varied set of historical facts
Natural language output ready to display on screen
The ability to request facts in a specific format or tone

How it works: A prompt is sent to the Gemini API each day with the current month and day, asking for a notable historical event:

const prompt = `
  Give me one interesting historical event that happened on ${month} ${day} 
  in any previous year. Keep it to 1-2 sentences. Be specific with the year.
`;

const response = await gemini.generateContent(prompt);
const fact = response.text();

The API returns something like: "49 years ago on this day, the first public screening of Star Wars generated enormous excitement among audiences who had never seen anything like it."

Why this matters for the channel: It transforms what could be a dry statistics update into something actually worth watching. Every video has a little historical surprise baked in. It gives viewers a reason to come back — not just for the percentage, but for the story of the day.

Step 3: Video Generation - Remotion

What it does: Takes the percentage and the historical fact and renders them into a polished, animated MP4 video - entirely in code.

What is Remotion? Remotion is a framework that lets you write videos using React. Instead of opening Premiere Pro or After Effects, you define your video as a React component. Animations, timing, transitions - all written in TypeScript. Then you render it to an actual video file using Node.js.

Why Remotion over other tools?

Full programmatic control - Every pixel, every animation, every timing decision is in code. No manual steps, no GUI.
Consistent output - The same code produces the same visual style every single day, automatically.
React-based - If you already know React, you're immediately productive.
High quality - Remotion renders frame-by-frame at whatever resolution and framerate you specify. The output is a proper video file, not a screen recording.

What the video looks like: A dark, minimal design with:

The year progress percentage in large type
A smooth animated progress bar filling to the correct point
Today's date
The historical fact rendered as clean text below
A short looping background animation for visual polish

The entire VideoTemplate.tsx component is just a React component with Remotion's <AbsoluteFill>, <spring>, and timing hooks to drive the animation.

export const VideoTemplate: React.FC<VideoProps> = ({ percentage, fact, date }) => {
  const frame = useCurrentFrame();
  const { fps } = useVideoConfig();

  const progress = spring({ frame, fps, config: { damping: 200 } });

  return (
    <AbsoluteFill style={{ background: '#0f0f1a' }}>
      <ProgressBar width={progress * percentage} />
      <PercentageText value={percentage} />
      <HistoricalFact text={fact} />
    </AbsoluteFill>
  );
};

Once the component is ready, rendering is a single CLI command (or programmatic call):

npx remotion render VideoTemplate out/video.mp4

Step 4: Uploading to YouTube - YouTube Data API v3

What it does: Takes the rendered MP4 and automatically uploads it to the YouTube channel with a title, description, and the correct Shorts formatting - no human involvement.

How the YouTube Data API works: Google provides an official API for interacting with YouTube programmatically. After a one-time OAuth2 authentication setup (where you grant your app permission to upload to your channel), you can upload videos, set metadata, manage playlists, and more - all from code.

The upload flow:

const youtube = google.youtube({ version: 'v3', auth: oauth2Client });

await youtube.videos.insert({
  part: ['snippet', 'status'],
  requestBody: {
    snippet: {
      title: `Year Progress Update - ${formattedDate}`,
      description: `${percentage}% of ${year} has passed.\n\n${historicalFact}`,
      tags: ['yearProgress', 'motivation', 'history'],
      categoryId: '22',
    },
    status: {
      privacyStatus: 'public',
    },
  },
  media: {
    body: fs.createReadStream('out/video.mp4'),
  },
});

Making it a YouTube Short: YouTube Shorts are simply vertical videos (9:16 aspect ratio) under 60 seconds. Remotion renders the video at 1080×1920, and that's all YouTube needs to classify it as a Short - no special API flag required.

The token refresh problem: OAuth2 tokens expire. To keep the automation running forever without manually re-authenticating, the app stores refresh tokens in tokens.json and automatically refreshes the access token before each upload. This is the kind of detail that separates a weekend project from something that actually keeps running for months.

Step 5: The Bash Script - Gluing It All Together

What it does: run-daily.sh is the conductor. It runs once a day and orchestrates the entire pipeline end-to-end.

Why a bash script? The core logic is in Node.js/TypeScript, but crontab (which triggers the daily run) works at the OS level. A bash script acts as the perfect bridge - it can set up the environment, invoke Node, handle errors, and maintain a log.

What the script does, step by step:

#!/bin/bash

PROJECT_DIR="/Users/mdshuvo/yearlyprogress"
STATE_FILE="$PROJECT_DIR/last-upload-date.txt"
LOG_FILE="$PROJECT_DIR/log.txt"

TODAY=$(date +%Y-%m-%d)

# Read the last run date
if [ -f "$STATE_FILE" ]; then
  LAST_RUN=$(cat "$STATE_FILE")
else
  LAST_RUN=""
fi

# Skip if already ran today
if [ "$LAST_RUN" = "$TODAY" ]; then
  exit 0
fi

cd "$PROJECT_DIR" || exit 1

# Run the main script, append output to log
/Users/mdshuvo/.nvm/versions/node/... >> "$LOG_FILE" 2>&1

# Trim the log to keep only the last 2000 lines
if [ -f "$LOG_FILE" ]; then
  tail -n 2000 "$LOG_FILE" > "$LOG_FILE.tmp" && mv "$LOG_FILE.tmp" "$LOG_FILE"
fi

Key design decisions:

Idempotency - The state file check ensures the script never accidentally uploads twice on the same day, even if crontab triggers it multiple times.
Logging - All output is appended to log.txt for easy debugging if something goes wrong.
Log trimming - The log is kept to 2,000 lines so it doesn't grow forever and fill up the disk.
nvm path - The full path to the Node binary is specified, because crontab runs in a minimal environment that doesn't load your shell's .bashrc or .zshrc. This is a classic gotcha that trips up many automation projects.

Step 6: The Crontab - Set It and Forget It

What it does: Tells my computer(Mac mini) to run run-daily.sh automatically at a set time every day.

What is crontab? It's a Unix job scheduler built into macOS and Linux. You define a schedule using a simple syntax, point it at a script, and the OS handles the rest - forever, or until you delete the entry.

The crontab entry:

0 9 * * * /Users/mdshuvo/yearlyprogress/run-daily.sh

This runs the script at 9:00 AM every day. The five fields represent: minute, hour, day of month, month, day of week. Five stars with the first two set means "every day at 9:00."

The result: Every morning at 9 AM, without any human action, computer runs the script, generates the video, and uploads it to YouTube. By the time most people are having their morning coffee, the day's video is live.

What Makes This Project Special

Beyond the individual pieces, what's interesting here is how each layer is chosen for a specific reason:

JavaScript for logic - Universal, fast to write, perfect for date manipulation and API calls.
Gemini for content - Turns a static metric into a story worth watching.
Remotion for video - Treats video like software, making it reproducible and automatable.
YouTube Data API for distribution - The last mile, handled entirely in code.
Bash for orchestration - Lightweight, reliable, and plays perfectly with crontab.
crontab for scheduling - The simplest possible scheduler, built into the OS.

No overengineering. No cloud infrastructure to manage. No monthly bills for a complex pipeline. Just a small computer, some clever code, and a crontab entry.

What's Next?

A few directions this project could grow:

Multiple languages - Generate the same video in Bengali, Spanish, French, etc. to reach broader audiences.
Milestone alerts - Special videos at 25%, 50%, 75%, and 99% with more elaborate animations.
Thumbnail generation - Use a canvas library or Puppeteer to auto-generate custom thumbnails.
Analytics tracking - Pull view counts back from the YouTube API and log the growth over time.
Multi-channel - Clone the pipeline for a "Day of the Year" or "Days Until New Year" variant.

Try It Yourself

All the core tools used are free or have generous free tiers:

Remotion - Free for open-source and personal projects
Google Gemini API - Free tier available
YouTube Data API v3 - Free with a Google account

If you want to watch the year tick away one percentage point at a time, the channel is live at youtube.com/@ProgressOfYear. A new video drops every morning.

Built with JavaScript, Remotion, Gemini

Why Traditional Tutorials Don't Work for Learning Git

Shuvo — Wed, 13 May 2026 04:57:00 +0000

If you've tried learning Git through videos or articles and still feel confused, you're not alone. The problem isn't you - it's the way Git is usually taught.

The Problem with Traditional Git Tutorials

Most tutorials focus on explaining commands instead of helping you understand how Git actually works in real situations.

They are passive (watching instead of doing)
They focus on syntax, not workflows
No real problem-solving scenarios
No feedback when you make mistakes

Why This Approach Fails

1. Git is Conceptual, Not Just Commands

Git involves understanding history, branches, and changes - not just memorizing commands.

2. No Muscle Memory

Watching tutorials doesn't build the habit of actually using Git commands.

3. No Real Context

Real development involves conflicts, mistakes, and workflows - tutorials rarely simulate this.

Traditional Learning vs Effective Learning

Method	Result
Watching tutorials	Temporary understanding
Reading docs	Good reference, low retention
Interactive practice	Real understanding

A Better Way to Learn Git

The most effective way to learn Git is through hands-on, interactive practice.

Learn a concept
Apply it immediately
Make mistakes and fix them
Repeat with real workflows

Stop Watching, Start Practicing

If you want to truly understand Git, you need to use it - not just watch someone else use it.

Frequently Asked Questions

Are tutorials useless for learning Git?
Not useless, but incomplete. They should be combined with hands-on practice.

Why does Git feel confusing?
Because it involves abstract concepts that require practice to fully understand.

What is the best way to learn Git?
The best way is practicing real workflows instead of relying only on passive learning.

Learn Git Basics in 5 Minutes (Quick Guide)

Shuvo — Wed, 13 May 2026 04:53:45 +0000

Want to learn Git fast? This 5-minute guide covers the essential Git concepts and commands you need to get started. No fluff - just the basics that actually matter.

What is Git?

Git is a version control system that helps you track changes in your code, collaborate with others, and manage different versions of your project.

3 Core Git Concepts

Repository (Repo)

A project folder tracked by Git.

Commit

A snapshot of your changes.

Branch

A separate line of development.

Essential Git Commands

Command	Description
`git init`	Initialize a new repository
`git add .`	Stage changes
`git commit -m "message"`	Save changes
`git status`	Check current state
`git branch`	View branches
`git checkout -b feature`	Create and switch branch
`git merge`	Merge branches

Basic Git Workflow

Make changes to your files
Run git add .
Run git commit -m "message"
Repeat as you build your project

Important: Reading Isn't Enough

You can't learn Git just by reading. You need to actually use the commands in real scenarios.

The fastest way to learn Git:

Learn a concept
Practice it immediately
Repeat with real workflows

Practice Git in Minutes

Instead of just reading, start practicing Git commands interactively and build real confidence.

Frequently Asked Questions

Can I learn Git in 5 minutes?
You can understand the basics in 5 minutes, but mastering Git requires practice.

What should I learn first in Git?
Start with repositories, commits, and basic commands like add and commit.

Is Git hard for beginners?
It can feel confusing at first, but becomes easy with hands-on practice.

Git Commands Senior Developers Actually Use

Shuvo — Wed, 13 May 2026 04:48:34 +0000

Want to use Git like a senior developer? It’s not about knowing hundreds of commands - it’s about mastering a small set of powerful ones and using them confidently in real workflows.

What Makes These Commands “Senior-Level”?

Senior developers don’t just run commands - they understand how Git history works, how to fix mistakes, and how to manage clean workflows. These commands reflect that mindset.

1. `git status`

Always Know What’s Happening

Check your current state before doing anything. Senior devs constantly use this.

2. `git log --oneline --graph --decorate`

Visualize History

See your commit history in a clean, readable format.

3. `git checkout -b feature-name`

Work in Branches

Create isolated environments for features and fixes.

4. `git merge`

Combine Work Safely

Merge branches when features are complete.

5. `git rebase`

Clean Up History

Rewrite commit history to keep it linear and clean.

6. `git stash`

Save Work Temporarily

Quickly store changes without committing.

7. `git reset`

Undo Changes

Move back to a previous state when needed.

8. `git restore`

Fix Mistakes Safely

Restore files without affecting commits.

9. `git pull --rebase`

Avoid Messy Merges

Keep history clean when pulling updates.

10. `git diff`

See What Changed

Understand exactly what modifications were made.

Practice These Commands Like a Pro

Reading commands isn’t enough - you need to actually use them in real workflows.

10 Git Mistakes Beginners Make (And How to Avoid Them)

Shuvo — Wed, 13 May 2026 04:40:12 +0000

Why Beginners Struggle with Git

Git isn’t just about commands - it’s about understanding how changes, history, and branches work together. Without hands-on practice, these concepts feel confusing.

10 Common Git Mistakes

1. Trying to Memorize Commands

Many beginners try to memorize Git commands instead of understanding what they actually do.
How to fix: Focus on workflows, not commands. Practice using Git in real scenarios.

2. Not Practicing Enough

Watching tutorials without actually using Git leads to shallow understanding.
How to fix: Use interactive practice to apply what you learn immediately. GitMission is great for that.

3. Ignoring Branching

Branching is a core concept, but many beginners avoid it.
How to fix: Practice creating, switching, and merging branches regularly.

4. Fear of Breaking Things

Beginners often hesitate because they’re afraid of making mistakes.
How to fix: Git is designed to recover changes - experiment freely.

5. Not Understanding Commits

Treating commits like random saves instead of meaningful checkpoints.
How to fix: Make small, descriptive commits that reflect logical changes.

6. Skipping Git Fundamentals

Jumping into advanced topics without understanding basics.
How to fix: Master repositories, commits, and staging first.

7. Confusion Between Git and GitHub

Many beginners mix up Git (tool) and GitHub (platform).
How to fix: Understand Git as the system, GitHub as a hosting service.

8. Poor Commit Messages

Using vague messages like 'update' or 'fix'.
How to fix: Write clear messages describing what changed and why.

9. Not Learning How to Undo Changes

Beginners panic when something goes wrong.
How to fix: Learn commands for undoing commits, restoring files, and fixing mistakes.

10. Avoiding Real Workflows

Only learning isolated commands instead of real use cases.
How to fix: Practice full workflows like feature development and merging.

The Real Secret to Learning Git

The biggest mistake is relying only on passive learning.

Learn a concept
Practice it immediately
Repeat with real scenarios

Learn Git Without These Mistakes

Instead of struggling through trial and error, you can learn Git the right way through structured, hands-on practice.

Functional tabs with only CSS (No JavaScript)

Shuvo — Wed, 04 Jun 2025 01:34:42 +0000

This article demonstrates how to create functional tabs using only CSS, without any JavaScript. The tabs will allow users to switch between different content sections seamlessly, showcasing the power of CSS for interactive elements.
Original article: wtfcodes.com

Basic setup:

To get started, we will create a typical HTML structure for our tabs and apply some basic styles to make them visually appealing.

<div class="tabs-wrapper">  
  <nav class="tabs-nav">
    <div class="tab-item">
      <span>Tab A</span>
    </div>
    <div class="tab-item">
      <span>Tab B</span>
    </div>
    <div class="tab-item">
      <span>Tab C</span>
    </div>

  </nav>

  <div class="tab-content" id="tab-a-content">
    I am Tab A content
  </div>
  <div class="tab-content" id="tab-b-content">
    I am Tab B content
  </div>
  <div class="tab-content" id="tab-c-content">
    I am Tab C content
  </div>
</div>

body{
  font-family: Arial;
  padding: 1em;
}

.tabs-nav{
  display: flex;
  gap: 8px;
  margin-bottom: 16px;
  user-select: none;
}

.tab-item{
  background: #bcbcbc;
  padding: 6px 12px;
  border-radius: 6px;
  color: #fff;
  cursor: pointer;
}
.tab-content{
  padding: 12px;
  border-radius: 16px;
  border: 1px solid grey;
}

Great! Now we need somekind of interactivity.
Lets think what cab we do so the active tab has something different than other tabs.
Well we can use <input type="radio" /> to indicate the active tab. Since radio inputs allow only one to be selected at a time, we can use them to control which tab is active.
And to make sure we can toggle the radio inputs by clicking on the tab, we can use the <label> element instead of <div> for the tab items.
So the updated HTML structure will look like this:

<div class="tabs-wrapper">  
  <nav class="tabs-nav">
    <label for="tab-a-toggle" class="tab-item">
      <span>Tab A</span>
      <input checked name="tabs-toggle" id="tab-a-toggle" type="radio">
    </label>
    <label for="tab-b-toggle" class="tab-item">
      <span>Tab B</span>
      <input name="tabs-toggle" id="tab-b-toggle" type="radio">
    </label>
    <label for="tab-c-toggle" class="tab-item">
      <span>Tab C</span>
      <input name="tabs-toggle" id="tab-c-toggle" type="radio">
    </label>
  </nav>

  <div class="tab-content" id="tab-a-content">
    I am Tab A content
  </div>
  <div class="tab-content" id="tab-b-content">
    I am Tab B content
  </div>
  <div class="tab-content" id="tab-c-content">
    I am Tab C content
  </div>
</div>

Nice progress!
Since we don't want the radio inputs to be visible, we can hide them using .tab-item input{display: none; } in the CSS.

Highlight the active tab:

We can use the tab-item:has(input:checked) selector in CSS to check if a tab has a checked input and apply styles to it.

.tab-item input{
  display: none;
}
.tab-item:has(input:checked){
  background: #6b54f0;
}

Amazing! Now we can see which tab is active.
Using the same logic, we can also show/hide the content of the active tab.

.tab-content{
  display: none;
}
.tabs-wrapper:has(#tab-a-toggle:checked) #tab-a-content{
  display: block;
}
.tabs-wrapper:has(#tab-b-toggle:checked) #tab-b-content{
  display: block;
}
.tabs-wrapper:has(#tab-c-toggle:checked) #tab-c-content{
  display: block;
}

Final code:

<div class="tabs-wrapper">  
  <nav class="tabs-nav">
    <label for="tab-a-toggle" class="tab-item">
      <span>Tab A</span>
      <input checked name="tabs-toggle" id="tab-a-toggle" type="radio">
    </label>
    <label for="tab-b-toggle" class="tab-item">
      <span>Tab B</span>
      <input name="tabs-toggle" id="tab-b-toggle" type="radio">
    </label>
    <label for="tab-c-toggle" class="tab-item">
      <span>Tab C</span>
      <input name="tabs-toggle" id="tab-c-toggle" type="radio">
    </label>
  </nav>

  <div class="tab-content" id="tab-a-content">
    I am Tab A content
  </div>
  <div class="tab-content" id="tab-b-content">
    I am Tab B content
  </div>
  <div class="tab-content" id="tab-c-content">
    I am Tab C content
  </div>
</div>

body{
  font-family: Arial;
  padding: 1em;
}

.tabs-nav{
  display: flex;
  gap: 8px;
  margin-bottom: 16px;
  user-select: none;
}

.tab-item{
  background: #bcbcbc;
  padding: 6px 12px;
  border-radius: 6px;
  color: #fff;
  cursor: pointer;
}
.tab-content{
  padding: 12px;
  border-radius: 16px;
  border: 1px solid grey;
}

.tab-item input{
  display: none;
}
.tab-item:has(input:checked){
  background: #6b54f0;
}

.tab-content{
  display: none;
}

.tabs-wrapper:has(#tab-a-toggle:checked) #tab-a-content{
  display: block;
}
.tabs-wrapper:has(#tab-b-toggle:checked) #tab-b-content{
  display: block;
}
.tabs-wrapper:has(#tab-c-toggle:checked) #tab-c-content{
  display: block;
}

Thank you for reading!

If you enjoyed this article, please consider sharing it with others.
You can support me on Buy Me a Coffee.
If you have any feedback or suggestions, feel free to reach out to me on Twitter.
Don't forget to checkout wtfcodes.com

When semicolon isn't optional in JavaScript

Shuvo — Mon, 02 Jun 2025 01:58:27 +0000

Original article: wtfcodes.com

TL;DR: In JavaScript, semicolons are optional at the end of statements, but there are specific cases where omitting them can lead to unexpected behavior or errors.

Without semicolon:

In the following example, I am trying to access an element in an array using idx variable and console log if the number is even or odd.
And since semicolon is optional in JavaScript, I have not used any semicolon at the end of the statement.

const array = [1, 2, 3, 4, 5, 6]
const idx = 2
const num = array[idx]
(num && num % 2 === 0)
            ? console.log("Even")
      : console.log("Odd")

Everything seems fine, right?
But wait, we got errors in the console.

With semicolon:

Now let's add semicolons at the end of the statements.

const array = [1, 2, 3, 4, 5, 6];
const idx = 2;
const num = array[idx];
(num && num % 2 === 0)
            ? console.log("Even")
      : console.log("Odd");

And look that, Everything works fine now!

And look that, Everything works fine now!

So WTF?

The deal breaker line here is const num = array[idx]. Because it is followed by (num && num % 2 === 0) ? console.log("Even") : console.log("Odd");

Why? Lets say our array contained functions that returns a number.

const fn1 = () => 1
const fn2 = () => 2
const fn3 = () => 3
const fn4 = () => 4
const fn5 = () => 5

const array = [ fn1, fn2, fn3, fn4, fn5 ]
const idx = 2
const num = array[idx]

console.log(num) //Output: function fn3() {}

It logs function fn3() {} in the console.
But we want num to be the return value of the function. So we need to call the function like this: const num = array[idx]() that way we are calling fn3 num will be the return value of the function.

const num = array[idx]()

console.log(num) //Output: 3

Since fn3 doesn't take any arguments, its deosnt matter if we pass any argument or not the function will still return the same value.
And we could also call the function in the next line and it will still work the same way.

//It doen't matter what we pass as argument
//Since fn3 doesn't take any argument, it will still return the same value
const num = array[idx]
(Math.random() > .5 ? 1 : 0)

console.log(num) //Output: 3

Did you catch it?

In our first example we were accidentally performing a function call on array[idx] which is a number and not a function, which is obviously wrong.
But when we add a semicolon at the end of the statement: const num = array[idx] the statement ends and the next line is treated as a new statement and not a function call.

const array = [1, 2, 3, 4, 5, 6]
const idx = 2
const num = array[idx]; //the semicolon ends the statement
//So the next line is treated as a new statement and not a function call
(num && num % 2 === 0)
            ? console.log("Even")
      : console.log("Odd")

Thank you for reading!

If you enjoyed this article, please consider sharing it with others.
You can support me on Buy Me a Coffee.
If you have any feedback or suggestions, feel free to reach out to me on Twitter.

I forgot about el.outerHTML so I made this

Shuvo — Mon, 07 Feb 2022 05:02:53 +0000

This morning I needed to convert a DOM element into a sting. And at the time I forgot about the el.outerHTML method. And I know the el.innerHTML will not include in element itself. It will only give inner HTML. So after doing a quick Google I was remined about the outerHTML method. And my issue was solved!

But this got me thinking how could I do it if there was no innerHTML or outerHTML method.
And thus htmlToString was born.

0shuvo0 / htmlToString

I forgot about el.outerHTML so I made this, it takes a DOM element and returns its html as string

htmlToString

Convert html/DOM element to string

Works with rendered and virtual DOM

Installation

npm install htmltostring

Or using CDN

<script src="https://cdn.jsdelivr.net/npm/htmltostring@1.0.6/htmlToString.min.js"></script>

Usage

//you don't have to import if you're using CDN
import htmlToString from 'htmltostring'

console.log(htmlToString('.container'))
// or 
// const container = document.querySelector('.container')
// console.log(htmlToString(container))

Example Output

<div class="container">
    <h1>Hello World</h1>
</div>

View on GitHub

And it was very simple to do using recursion.

There was just three main question.

What's the tag name of the element
How to get all the attributes present on a HTML element
Check if a tag is self closing tag or not

And here are the answers

What's the tag name of the element

You can easily get the tag name of the element like this

let tagName = el.tagName.toLowerCase()

How to get all the attributes present on a HTML element

el.attributes returns a list of attribute present on the element.

[...el.attributes].map(e => `${e.name}="${e.value}"`).join(" ")

//example outcome
//'class="main" type="text"'

Check if a tag is self closing tag or not

First we can create an array or self closing tags and then check if tag name is present in the array

const selfClosingTags = ['area', 'base', 'br', 'col', 'embed', 'hr', 'img', 'input', 'link', 'meta', 'param', 'source', 'track', 'wbr']
if(selfClosingTags.includes(tagName)){
    console.log("Self closing tag")
}

And with all the questions answered the function was very easy to implement.
You can see the full code here

Found it useless, I mean helpful? By me a Coffee ☕

Make sure you checkout my other articles and YouTube channel

ShuvoFollow

DEVELOPER

Support me on Patreon

Let's create an Add Tags input with REACT JS

Shuvo — Mon, 17 Jan 2022 03:57:25 +0000

In this article I will show you guys how you can create this multiple tags input using React.JS and a bit of CSS

Lets create a new react js project by running npx create-react-app myapp
Now to simplify things I am goin to delete all the files inside src folder except for App.js and index.js and create a style.css file. So our folder structure should look like this
Great now let's also delete all the unnecessary codes from index.js and App.js

// src/index.js
import React from 'react';
import ReactDOM from 'react-dom';
import "./style.css";
import App from './App';

ReactDOM.render(
  <React.StrictMode>
    <App />
  </React.StrictMode>,
  document.getElementById('root')
);

// src/App.js
function App() {
  return (
    <div className="App">
      <h2>Enter Some Tags ...</h2>
    </div>
  );
}

export default App;

And I am also goin to add these CSS styles in our src/index.js

*{
    margin: 0;
    padding: 0;
}
html, body{
    height: 100%;
}
body{
    display: flex;
    justify-content: center;
    align-items: center;
    font-family: 'Courier New', Courier, monospace;
    font-weight: bold;
}

.tags-input-container{
    border: 2px solid #000;
    padding: .5em;
    border-radius: 3px;
    width: min(80vw, 600px);
    margin-top: 1em;
    display: flex;
    align-items: center;
    flex-wrap: wrap;
    gap: .5em;
}

.tag-item{
    background-color: rgb(218, 216, 216);
    display: inline-block;
    padding: .5em .75em;
    border-radius: 20px;
}
.tag-item .close{
    height: 20px;
    width: 20px;
    background-color: rgb(48, 48, 48);
    color: #fff;
    border-radius: 50%;
    display: inline-flex;
    justify-content: center;
    align-items: center;
    margin-left: .5em;
    font-size: 18px;
    cursor: pointer;
}

.tags-input{
    flex-grow: 1;
    padding: .5em 0;
    border: none;
    outline: none;
}

If you want better explanation of the CSS you can watch this video of mine.

Okay now if we were to start our app by running npm start it should look like this

Alright now lets create a folder inside src folder named components inside that we are going to create a component file called TagsInput.js

// src/components/TagsInput.js
function TagsInput(){
    return (
        <div className="tags-input-container">
            <div className="tag-item">{/* One hardcoded tag for test */}
                <span className="text">hello</span>
                <span className="close">&times;</span>
            </div>
            <input type="text" className="tags-input" placeholder="Type somthing" />
        </div>
    )
}

export default TagsInput

Now we can import and use in our App.js

// src/App.js
import TagsInput from "./components/TagsInput"

function App() {
  return (
    <div className="App">
      <h2>Enter Some Tags ...</h2>
      <TagsInput />
    </div>
  );
}

export default App;

Great, but no instead of having a hardcoded tag like this, we want an array and we should loop over the array and show a tag for each element. So lets use useState to do that

// src/components/TagsInput.js
import { useState } from 'react'

function TagsInput(){
    const [tags, setTags] = useState([
        "HTML", "CSS", "JavaScript"
    ])
    return (
        <div className="tags-input-container">
            { tags.map((tag, index) => (
                <div className="tag-item" key={index}>
                    <span className="text">{tag}</span>
                    <span className="close">&times;</span>
                </div>
            )) }
            <input type="text" className="tags-input" placeholder="Type somthing" />
        </div>
    )
}

export default TagsInput

Okay now by default our array should be empty and when we type something in our input and press Enter a new item should be added in our tags state array. So lets create a function for that and add onKeyDown event listener to our input.

// src/components/TagsInput.js
import { useState } from 'react'

function TagsInput(){
    const [tags, setTags] = useState([])

    function handleKeyDown(e){
        // If user did not press enter key, return
        if(e.key !== 'Enter') return
        // Get the value of the input
        const value = e.target.value
        // If the value is empty, return
        if(!value.trim()) return
        // Add the value to the tags array
        setTags([...tags, value])
        // Clear the input
        e.target.value = ''
    }

    return (
        <div className="tags-input-container">
            { tags.map((tag, index) => (
                <div className="tag-item" key={index}>
                    <span className="text">{tag}</span>
                    <span className="close">&times;</span>
                </div>
            )) }
            <input onKeyDown={handleKeyDown} type="text" className="tags-input" placeholder="Type somthing" />
        </div>
    )
}

export default TagsInput

And now finally when even user clicks on the
close(x) button of a tag the tag should be removed from our tags array. So lets create a function that take a index as its argument and removes the item at that index from our tags array. And add onClick listener to the close buttons.

// src/components/TagsInput.js
import { useState } from 'react'

function TagsInput(){
    const [tags, setTags] = useState([])

    function handleKeyDown(e){
        if(e.key !== 'Enter') return
        const value = e.target.value
        if(!value.trim()) return
        setTags([...tags, value])
        e.target.value = ''
    }

    function removeTag(index){
        setTags(tags.filter((el, i) => i !== index))
    }

    return (
        <div className="tags-input-container">
            { tags.map((tag, index) => (
                <div className="tag-item" key={index}>
                    <span className="text">{tag}</span>
                    <span className="close" onClick={() => removeTag(index)}>&times;</span>
                </div>
            )) }
            <input onKeyDown={handleKeyDown} type="text" className="tags-input" placeholder="Type somthing" />
        </div>
    )
}

export default TagsInput

And that's all we have successfully create a tags input using React and Bit of JavaScript.

Found it helpful? By me a Coffee ☕

Make sure you checkout my other articles and YouTube channel

ShuvoFollow

DEVELOPER

DEV Community: Shuvo

Before AI we had ...

Frontend rate limiting can save you $10,000

1: Basic frontend rate limiter example:

2. Better rate limiter with cooldown time and localstorage implementation so user can't just reset limit by refreshing the page

When to Use Frontend Rate Limiting

When Not to Use Frontend Rate Limiting

Your trycatch sucks - lets fix it

🤦 Level 0: The "Trust Me Bro" Dev

🐣 Level 1: The Junior — "I Googled try/catch"

📈 Level 2: The Mid-Level — "I've Been Burned Before"

2a — Typed errors, real messages

2b — Undo previous operations (the "atomic mindset")

2c — Wrap it in a clean utility (stop repeating yourself)

🧠 Level 3: The Senior — "I've Seen Things"

3a — Retry queue with exponential backoff

3b — Circuit breaker (stop hammering a dead service)

3c — Structured error classes (errors that mean something)

🗺️ The Full Picture

✅ The Golden Rules

I Built a Fully Automated YouTube Channel That Uploads Every Day - Without Touching It

The Idea: Simple, But Strangely Satisfying

The Tech Stack at a Glance

Step 1: The Math - How Much of the Year Has Passed?

Step 2: The History Hook - Google Gemini API

Step 3: Video Generation - Remotion

Step 4: Uploading to YouTube - YouTube Data API v3

Step 5: The Bash Script - Gluing It All Together

Step 6: The Crontab - Set It and Forget It

What Makes This Project Special

What's Next?

Try It Yourself

Why Traditional Tutorials Don't Work for Learning Git

The Problem with Traditional Git Tutorials

Why This Approach Fails

1. Git is Conceptual, Not Just Commands

2. No Muscle Memory

3. No Real Context

Traditional Learning vs Effective Learning

A Better Way to Learn Git

Stop Watching, Start Practicing

Frequently Asked Questions

Learn Git Basics in 5 Minutes (Quick Guide)

What is Git?

3 Core Git Concepts

Repository (Repo)

Commit

Branch

Essential Git Commands

Basic Git Workflow

Important: Reading Isn't Enough

Practice Git in Minutes

Frequently Asked Questions

Git Commands Senior Developers Actually Use

What Makes These Commands “Senior-Level”?

1. git status

2. git log --oneline --graph --decorate

3. git checkout -b feature-name

4. git merge

5. git rebase

6. git stash

7. git reset

8. git restore

9. git pull --rebase

10. git diff

Practice These Commands Like a Pro

10 Git Mistakes Beginners Make (And How to Avoid Them)

Why Beginners Struggle with Git

10 Common Git Mistakes

1. Trying to Memorize Commands

2. Not Practicing Enough

3. Ignoring Branching

4. Fear of Breaking Things

5. Not Understanding Commits

6. Skipping Git Fundamentals

7. Confusion Between Git and GitHub

8. Poor Commit Messages

9. Not Learning How to Undo Changes

10. Avoiding Real Workflows

The Real Secret to Learning Git

1. `git status`

2. `git log --oneline --graph --decorate`

3. `git checkout -b feature-name`

4. `git merge`

5. `git rebase`

6. `git stash`

7. `git reset`

8. `git restore`

9. `git pull --rebase`

10. `git diff`