Forem: Suraj

Fix Wrong Authors Commits the Safe Way Using Git Rebase

Suraj — Sun, 05 Oct 2025 13:51:30 +0000

Introduction

Ever committed code with the wrong Git author? Whether you're juggling personal and work accounts or just forgot to configure your identity in a new project, this happens to the best of us. The good news? You can fix it safely and in this guide, we'll do it the smart way using a Docker sandbox plus real GitHub practice.

What You'll Learn

Git rebase fundamentals (interactive mode explained simply)
Three real-world scenarios for fixing wrong authors
Safe Docker lab environment (no risk to your actual Git setup)
Hands-on GitHub practice (see the fixes in action)

Why This Approach Works

Docker Container: Keeps your global Git config safe while you experiment

Real GitHub Repo: See the actual before/after results in GitHub's UI

Progressive Scenarios: From simple local fixes to complex merged commits

We'll simulate this common mistake:

Global user (wrong) → surajdeveloper <surajdeveloper@example.com> → You have made commit with this
Repo user (correct) → surajdevops <surajdevops@example.com> → But you should have made the commit with this.

Git Rebase : The Foundation

Before diving into fixes, let's understand why we use Git rebase for author corrections.

What is Git Rebase?

Takes your commits and replays them on top of another branch, creating a straight line history.

git rebase main

What it does:

Moves your commits to the tip of main branch
Creates new commit IDs (rewrites history)
Makes history look like you worked on the latest code all along

What is Git Merge?

Git Merge = Combines two branches by creating a merge commit that joins them together.

git merge feature

What it does:

Keeps original commits unchanged
Creates one new "merge commit"
Preserves the branching structure

When to Use?

Merge: When working with others on the same branch
Rebase: When cleaning up your local commits before opening a PR

Golden Rule: Never rebase shared branches!

Why Use Interactive Rebase for Fixes?

If you only need to fix the latest commit, you can use:

git commit --amend --author="Correct Name <correct@email.com>"

But if the wrong author is buried in the middle of history, you need to:

Stop at that specific commit
Fix the author information
Replay the remaining commits

That's exactly what git rebase -i (interactive rebase) does!

Rebase vs Merge: Quick Comparison

Merge = Combines two branches while preserving original commit history
Rebase = Replays commits on a new base, rewriting history for a clean linear timeline

Interactive Rebase: What Happens Under the Hood

When you run git rebase -i HEAD~3, here's the journey:

Visual: Before & After (Actual Git Output)

Before (wrong author on commits):

$ git log --oneline --graph --pretty=format:'%h - %an <%ae> - %s'
* 9a3f8d2 - surajdeveloper <surajdeveloper@example.com> - Add gitignore
* 7b2c4e1 - surajdeveloper <surajdeveloper@example.com> - Add main application file
* 5d1a3b9 - surajdevops <surajdevops@example.com> - Initial commit

Notice commits 9a3f8d2 and 7b2c4e1 have the wrong author (surajdeveloper).

During interactive rebase:

$ git rebase -i HEAD~3
# Editor opens showing:
pick 5d1a3b9 Initial commit
pick 7b2c4e1 Add main application file
pick 9a3f8d2 Add gitignore

# You change it to:
pick 5d1a3b9 Initial commit
edit 7b2c4e1 Add main application file  # <- mark as edit
edit 9a3f8d2 Add gitignore              # <- mark as edit

After fixing with rebase + amend:

$ git log --oneline --graph --pretty=format:'%h - %an <%ae> - %s'
* 2f8a9c5 - surajdevops <surajdevops@example.com> - Add gitignore
* 4e7b3d1 - surajdevops <surajdevops@example.com> - Add main application file
* 5d1a3b9 - surajdevops <surajdevops@example.com> - Initial commit

✅ All commits now show the correct author (surajdevops)!

⚠️ Note: The commit hashes changed (9a3f8d2 → 2f8a9c5) because we rewrote history.

🐳 Setting Up Your Docker Git Lab: Let's do it hands-on

Let's create a completely isolated environment for safe experimentation.

Build & Run the Lab with the Docker image and clone the GitHub repo:

Image: https://hub.docker.com/r/surajkumar00/git-rebase-lab

GitHub repo: https://github.com/Suraj-kumar00/learn-git

Run interactive container

# Run interactive container
docker run -it --rm surajkumar00/git-rebase-lab

git clone https://github.com/Suraj-kumar00/learn-git.git
cd learn-git

You're now inside a clean Ubuntu container and GitHub repo with Git ready to go!

Lab Exercise: Creating the Problem

Let's simulate the real-world scenario where you accidentally use the wrong Git identity.

Step 0: Create a feature branch

git checkout -b feature

# Check the branch
git branch

Step 1: Set Wrong Global Identity

Inside the Docker container:

git config --global user.name "surajdeveloper"
git config --global user.email "surajdeveloper@example.com"

# Verify it's set
git config --global --list
# or
git config --list

Step 2: Let's make some Commits

echo "console.log('Hello World');" > app.js
git add app.js
git commit -m "Add main javascript application file"

echo "print('Hello World')" > main.py
git add main.py
git commit -m "Add main python application file"

echo "node_modules/" > .gitignore
git add .gitignore
git commit -m "Add gitignore"

Step 3: Check the Damage

git log

# or

git log --oneline

# or

git log --pretty=format:"%h %an <%ae> %s"

Output shows all commits have the wrong author:

a1b2c3d surajdeveloper <surajdeveloper@example.com> Add gitignore
b4c5d6e surajdeveloper <surajdeveloper@example.com> Add main python application file
c7d8e9f surajdeveloper <surajdeveloper@example.com> Add main javascript application file

Step 4: Set Correct Repo-Level Identity

git config user.name "surajdevops"
git config user.email "surajdevops@example.com"

# Verify repo config overrides global
git config user.name
git config user.email

New commits will now use the correct author, but what about the existing ones?

Scenario 1: Fix Local Commits (Before Push)

This is the safest scenario — commits exist only on your local machine.

Interactive Rebase in Action

# Start interactive rebase for last 3 commits
git rebase -i HEAD~3

This opens your editor with something like:

pick c7d8e9f Add main javascript application file
pick b4c5d6e Add main python application file
pick a1b2c3d Add gitignore

# Commands:
# p, pick <commit> = use commit
# e, edit <commit> = use commit, but stop for amending
# r, reword <commit> = use commit, but edit the commit message

Mark Commits for Editing

Change pick to edit for commits you want to fix:

edit c7d8e9f Add main javascript application file
edit b4c5d6e Add main python application file
edit a1b2c3d Add gitignore

Save and exit (in vim: esc shift+: press x)

Fix Each Commit

Git will stop at each commit marked for editing:

# When Git pauses at first commit
git commit --amend --author="surajdevops <surajdevops@example.com>" --no-edit

# Continue to next commit
git rebase --continue

# Repeat for each commit Git stops at

Verify the Fix

git log --pretty=format:"%h %an <%ae> %s"

Now all commits show the correct author! ✅

Scenario 1.1: Fix Initial Commit (Including Root)

Special case: What if the initial commit also has the wrong author? Regular HEAD~N won't include the root commit.

The Problem: Initial Commit Has Wrong Author

git log --pretty=format:"%h %an <%ae> %s"

Output shows:

a1b2c3d surajdeveloper <surajdeveloper@example.com> Add gitignore
b4c5d6e surajdeveloper <surajdeveloper@example.com> Add main python application file
c7d8e9f surajdeveloper <surajdeveloper@example.com> Add main javascript application file
d8e9f0g surajdeveloper <surajdeveloper@example.com> Initial commit  ← WRONG!

The Solution: Use `-root` Flag

# Include the initial commit in interactive rebase
git rebase -i --root

This opens the editor with ALL commits including the root:

pick d8e9f0g Initial commit          ← Root commit included!
pick c7d8e9f Add main javascript application file
pick b4c5d6e Add main python application file
pick a1b2c3d Add gitignore

Mark Commits (Including Root) for Editing

edit d8e9f0g Initial commit          ← Fix the root!
edit c7d8e9f Add main javascript application file
edit b4c5d6e Add main python application file
edit a1b2c3d Add gitignore

Fix Each Commit (Same Process)

# Git stops at root commit first
git commit --amend --author="surajdevops <surajdevops@example.com>" --no-edit
git rebase --continue

# Continue for each subsequent commit...

Why `-root` is Essential

Regular rebase (HEAD~4) excludes the initial commit
Root rebase (-root) includes everything from the beginning
This is the only way to edit the initial commit's author

Scenario 2: Wrong Author Already Pushed (Branch Not Merged)

If you've already pushed the commits to a feature branch (but not merged to main), you can still fix them.

Setup: Push to Remote Branch

First, let's simulate this scenario:

# Create a feature branch (if not already on one)
git checkout -b feature/user-auth

# Push to remote (if you have access to push)
git push -u origin feature/user-auth

Fix and Force Push

After fixing the commits locally (using the same rebase process above):

# Force push the corrected history
git push origin feature/user-auth --force

⚠️ Important Warnings:

Only force push if you own the branch
Coordinate with your team before rewriting pushed history
Never force push to main or master without team agreement

Scenario 3: Wrong Author Already Merged to Main

This is the most complex scenario. Once commits are merged into the main branch, rewriting history becomes dangerous.

Option 1: Accept and Document (✅ Recommended)

Best practice → Don't rewrite main branch history. Instead, add documentation:

git commit --allow-empty -m "docs: commits abc123-def456 were authored by surajdevops, not surajdeveloper"

Option 2: Rewrite Main (⚠️ Dangerous)

Only do this if:

Your entire team agrees
You can coordinate a synchronized reset for all team members
The repository is not public or widely used

# Fix commits using rebase
git rebase -i HEAD~5  # Adjust number as needed

# Force push main (DANGEROUS!)
git push origin main --force

# All team members must then:
# git fetch origin
# git reset --hard origin/main

Advanced Tips & Best Practices

For this you can read my this blog Managing Multiple GitHub/Git Accounts on One Machine (Personal + Work)

Prevent Future Mistakes

Set repo-specific config immediately in new projects:

# Right after git clone or git init
git config user.name "Your Correct Name"
git config user.email "your.correct@email.com"

Create Git aliases for quick identity switching:

# Add to ~/.gitconfig
git config --global alias.work 'config user.email "work@company.com"'
git config --global alias.personal 'config user.email "personal@gmail.com"'

# Usage: git work or git personal

When NOT to Rewrite History

Never rewrite history when:

❌ Commits already merged to main/master
❌ Public repositories with external contributors
❌ Other team members have based work on your commits
❌ CI/CD systems have already processed the commits
❌ The commits have been tagged for a release

Quick Reference: Rebase Commands

# Fix last commit only
git commit --amend --author="Name <email>"

# Fix multiple recent commits
git rebase -i HEAD~N  # N = number of commits

# Fix commits including the initial commit
git rebase -i --root

# Fix commits after specific commit
git rebase -i abc123^  # abc123 = commit hash

# Abort rebase if something goes wrong
git rebase --abort

# Skip a problematic commit during rebase
git rebase --skip

Complete Setup Commands Summary

# 1. Run the Docker lab
docker run -it --rm surajkumar00/git-rebase-lab

# 2. Clone the practice repo
git clone https://github.com/Suraj-kumar00/learn-git.git
cd learn-git

# 3. Create feature branch
git checkout -b feature

# 4. Set wrong identity and create commits
git config --global user.name "surajdeveloper"
git config --global user.email "surajdeveloper@example.com"

# 5. Make commits (will have wrong author)
echo "console.log('Hello World');" > app.js && git add app.js && git commit -m "Add main javascript application file"
echo "print('Hello World')" > main.py && git add main.py && git commit -m "Add main python application file"
echo "node_modules/" > .gitignore && git add .gitignore && git commit -m "Add gitignore"

# 6. Set correct identity
git config user.name "surajdevops"
git config user.email "surajdevops@example.com"

# 7. Fix the commits

# or git rebase -i --root for initial commit
git rebase -i HEAD~3

# Change 'pick' to 'edit', then for each commit:
git commit --amend --author="surajdevops <surajdevops@example.com>" --no-edit
git rebase --continue

# 8. Verify the fix
git log --pretty=format:"%h %an <%ae> %s"

Your Next Steps

Configure proper Git identities in all your current projects to prevent future mistakes
Share this guide with your team to prevent future author mix-ups

Remember: Git is powerful, but with great power comes great responsibility hehe. Always practice in safe environments before applying these techniques to important repositories!

Happy rebasing!

Found this helpful? Star the practice repo and share with your team! Questions or improvements? Open an issue on the above GitHub repo.

Why NGINX Still Powers the Modern Web in 2025: Part 1

Suraj — Wed, 27 Aug 2025 16:13:46 +0000

NGINX Fundamentals: Architecture, Configuration, and Real-Time Hands-On Practice

Introduction

NGINX has revolutionized modern web infrastructure, becoming the backbone of high-performance applications worldwide. In this part 1 you'll learn about NGINX fundamentals configurations, theoretical knowledge with real-time scenario examples.

Originally developed by Igor Sysoev in 2004, NGINX was created to solve the infamous C10K problem and has since evolved into one of the most powerful and widely adopted web servers in the world.

What is Forward Proxy and Reverse Proxy?

Understanding proxy servers is fundamental to grasping NGINX's core functionality, as it excels primarily as a reverse proxy server.

Forward Proxy:

A forward proxy acts as an intermediary between clients and the internet, sitting on the client side of the network.

Key Characteristics:

Acts on behalf of the client
Sits between client and the public internet
Forwards client requests to servers
Server doesn't know which specific client made the request
Primarily serves client needs

Real-World Example: Corporate networks use forward proxies to:

Filter employee internet access
Block social media and non-work websites
Cache frequently accessed content to save bandwidth
Provide anonymity for internal users
Monitor and log internet usage

Reverse Proxy:

A reverse proxy sits between clients and backend servers, acting on behalf of the server infrastructure.

Key Characteristics:

Acts on behalf of the server
Sits between internet clients and backend servers
Hides server implementation details from clients
Distributes incoming requests across multiple backend servers
Provides additional services like SSL termination, caching, and load balancing

Real-World Example: Netflix, Amazon, and Google use reverse proxies to:

Distribute user requests across thousands of servers worldwide
Cache popular content closer to users
Terminate SSL connections at the edge
Provide DDoS protection and security filtering
Ensure high availability and fault tolerance

What is DMZ?

A DMZ (Demilitarized Zone) is a physical or logical subnetwork that adds an extra layer of security to an organization's network by isolating publicly accessible services, such as web or email servers, from the main internal network.

Understanding NGINX: Architecture & Use Cases

What is NGINX?

NGINX (pronounced "engine-x") is a widely used open-source tool that does much more than just serve web pages. Known for its speed and reliability, it also works as a reverse proxy, load balancer, and caching server. Whether you're streaming media, handling email protocols like SMTP or IMAP, or routing HTTP and TCP traffic, NGINX is built to handle it all with efficiency.

Core Capabilities:

Web Server: Serving static and dynamic content with minimal resource usage
Reverse Proxy: Forwarding client requests to backend application servers
Load Balancer: Distributing incoming traffic across multiple backend servers
HTTP Cache: Storing frequently requested content to reduce backend load
SSL/TLS Termination: Handling encryption/decryption at the network edge
Mail Proxy: Managing SMTP, POP3, and IMAP protocol connections
Stream Proxy: Handling TCP and UDP traffic for various applications

What problem it solves?

NGINX was specifically designed to solve the C10K problem - the challenge of handling 10,000 (or more) concurrent client connections on a web server efficiently.

The Traditional Problem: Before NGINX, traditional web servers like Apache used a process-per-connection or thread-per-connection model:

This approach became unsustainable as:

Each connection consumed significant memory (8-12MB per process)
Context switching between processes became expensive
System resources were quickly exhausted
Performance degraded dramatically under high load

NGINX's Solution: NGINX was built to solve this problem using an asynchronous, event-driven model, making it lightweight and able to handle tens of thousands of connections simultaneously efficiently and reliably.

Why NGINX Became Essential:

The traditional web servers like Apache used a process-per-connection model, which became inefficient as web traffic grew exponentially. Each connection required a separate process or thread, consuming significant memory and CPU resources. NGINX's innovative approach changed this paradigm entirely.

NGINX Architecture: The Process Model

NGINX uses an event-driven, asynchronous architecture that sets it apart from traditional web servers and consists of several components such as*:*

Master process – Controls the main NGINX instance. It manages configuration, and is responsible for starting, stopping, and supervising the worker processes.
Worker processes – Handle all the actual work: managing client connections, serving static content, proxying requests, load balancing, and SSL/TLS termination.
Cache loader – Runs at startup to load cache metadata from disk into memory, making cached content immediately available after NGINX boots.
Cache manager – Runs in the background at intervals to check the cache directory, remove expired data, and ensure disk usage stays within limits.
Shared memory – Provides inter-process communication and storage for shared state, such as cache indexes, rate limiting counters, and load-balancing information.

Why This Architecture Matters:

Memory Efficiency: One worker can handle thousands of connections with minimal memory overhead
CPU Efficiency: No context switching between processes for each request
Scalability: Performance degrades gracefully under high load
Stability: If a worker crashes, the master spawns a new one without affecting other connections
Resource Optimization: Efficient use of system resources leads to better overall performance

Core Use Cases

NGINX's versatility makes it suitable for numerous deployment scenarios:

Web Server: Serving static content (HTML, CSS, JS, images) with minimal overhead
Reverse Proxy: Forwarding requests to backend applications

NGINX Alternatives

While NGINX is widely used, a few alternatives are worth knowing:

Apache HTTP Server – A long-standing web server with strong legacy support and a rich module ecosystem, but less efficient under heavy load compared to NGINX.
HAProxy – Specializes in high-performance load balancing and traffic distribution. Great for reliability, but not designed to serve static content.
Traefik – A modern, cloud-native reverse proxy with built-in support for containers, service discovery, and automatic SSL management.
Cloudflare (as a Service) – A managed CDN and security platform offering DDoS protection, WAF, and global content delivery but relies on a third-party provider.

Setting Up Nginx with Docker: Hands-On

Prerequisites

Before we begin, ensure you have Docker installed on your system. You can download it from Docker's official website.

Step 1: Setting Up the Docker Container

Let's start by creating and running an Ubuntu container with Nginx:

docker run -it --name nginx-docker -p 8080:80 ubuntu

Command Breakdown:

name nginx-docker → Assigns a custom name to your container
p 8080:80 → Maps your host machine's port 8080 to the container's port 80
it ubuntu → Creates an interactive terminal session with Ubuntu

This command will download the Ubuntu image (if not already present) and start an interactive container session.

Step 2: Installing Nginx and Essential Tools

Once inside the container, update the package list and install Nginx:

# Update package repositories
apt update

# Install Nginx web server
apt install nginx -y

# Install vim text editor (useful for editing config files)
apt install vim -y

After running the apt install vim -y command first choose number 5 which is Asia and then choose 44 It’s Kolkata, we are choosing these to install IST timezone while installing the vim tool.

Pro Tip: Always run apt update first to ensure you're installing the latest versions of packages.

Step 3: Verify Nginx Installation

Check if Nginx was installed successfully:

nginx -v
or
nginx -V

You should see output similar to: nginx version: nginx/1.18.0 (Ubuntu)

Step 4: Understanding Nginx Directory Structure

After installation, all Nginx files are stored in /etc/nginx. Let's explore this directory:

cd /etc/nginx
ls -la

You'll see a structure like this:

drwxr-xr-x 8 root root 4096 Aug 19 13:38 ./
drwxr-xr-x 1 root root 4096 Aug 19 13:36 ../
drwxr-xr-x 2 root root 4096 May 27 10:28 conf.d/
-rw-r--r-- 1 root root 1125 Dec  1  2023 fastcgi.conf
-rw-r--r-- 1 root root 1055 Dec  1  2023 fastcgi_params
-rw-r--r-- 1 root root 5465 Dec  1  2023 mime.types
drwxr-xr-x 2 root root 4096 May 27 10:28 modules-available/
drwxr-xr-x 2 root root 4096 May 27 10:28 modules-enabled/
-rw-r--r-- 1 root root 1446 Aug 19 13:37 nginx.conf
-rw-r--r-- 1 root root  636 Dec  1  2023 scgi_params
drwxr-xr-x 2 root root 4096 Aug 19 13:24 sites-available/
drwxr-xr-x 2 root root 4096 Aug 19 13:24 sites-enabled/
drwxr-xr-x 2 root root 4096 Aug 19 13:24 snippets/

Key Files and Directories:

nginx.conf → Main configuration file (most important!)
sites-available/ → Contains individual site configurations
sites-enabled/ → Contains symlinks to active site configurations
conf.d/ → Additional configuration files

Step 5: Managing Nginx Service

Starting Nginx

To start the Nginx service:

service nginx start

When to use: After installation or when Nginx has been stopped.

Checking Nginx Status

To verify Nginx is running:

service nginx status

Alternative method to check running processes:

ps aux | grep nginx

You should see output showing:

nginx: master process (main Nginx process)
nginx: worker process (handles actual requests)

Stopping Nginx

When you need to stop Nginx:

service nginx stop

When to use: During maintenance, troubleshooting, or when shutting down your server.

Step 6: Testing Your Nginx Installation

Since we mapped port 80 to 8080, open your web browser and navigate to:

http://localhost:8080

You should see the default Nginx Welcome Page!

Important Note: Nginx runs on port 80 by default, but since we're using Docker, we've mapped container port 80 to host port 8080. Make sure no other service is using port 8080 on your host machine.

Step 7: Creating a Custom Configuration

Now let's customize Nginx with our own configuration.

Backup the Original Configuration

Always backup before making changes:

cd /etc/nginx
mv nginx.conf nginx-backup.conf

Create New Configuration File

You can either create an empty file first or directly edit:

# Option 1: Create empty file then edit
touch nginx.conf
vim nginx.conf

# Option 2: Directly create and edit
vim nginx.conf

Add Custom Configuration

Insert the following content into your new nginx.conf:

events {
    worker_connections 1024;
}

http {
    server {
        listen 80;
        server_name _;

        location / {
            return 200 "Hello from Nginx Custom Configuration via Docker\\n";
            add_header Content-Type text/plain;
        }
    }
}

How to exit the vim editor: After pasting this, press esc and then shift + : and the press x and press enter

Configuration Breakdown:

events → Defines connection processing parameters
worker_connections 1024 → Maximum connections per worker process
http → Main HTTP context
listen 80 → Port Nginx listens on
server_name _ → Catch-all server name
location / → Handles all requests to root path
return 200 → Returns HTTP 200 status with custom message

Step 8: Testing and Reloading Configuration

Test Configuration Syntax

Before applying changes, always test the configuration:

nginx -t

You should see something like this:

Reload Configuration

If the test passes, reload Nginx to apply changes:

nginx -s reload

Why reload instead of restart?

reload → Applies new configuration without dropping existing connections
restart → Stops and starts Nginx, dropping all connections

Verify Your Changes

Visit http://localhost:8080 again. You should now see your custom message: "Hello from Nginx Custom Configuration via Docker"

Common Commands Summary

Here's a quick reference of essential Nginx commands:

# Service management
service nginx start     # Start Nginx
service nginx stop      # Stop Nginx
service nginx status    # Check status
service nginx restart   # Full restart

# Configuration management
nginx -t               # Test configuration
nginx -s reload        # Reload configuration
nginx -s stop          # Graceful stop
nginx -s quit          # Graceful shutdown

# Information
nginx -v              # Show version
nginx -V              # Show version and compile options

In the next parts of this nignx blogs we’ll learn:

Now that you have a basic Nginx setup running, you can explore:

Serving static files
Setting up reverse proxy
SSL/TLS configuration
Load balancing
Custom error pages

Conclusion

You've successfully set up Nginx in a Docker container, learned how to manage the service, and created your first custom configuration. This foundation will serve you well as you continue your journey with web servers and containerization.

Remember: Always test your configurations before applying them, and keep backups of working configurations. Happy learning!

Thanks for reading…

Git Cherry-Pick Saved My Messed-Up Branch — Here’s How You Can Too!

Suraj — Tue, 01 Jul 2025 17:56:22 +0000

Introduction

A practical, real-world guide to understanding and applying Git cherry-pick with actual developer mistakes and fixes.

What is `git cherry-pick`?

git cherry-pick lets you selectively apply commits from one branch to another — like copying specific code changes without merging entire branches.

Now let’s understand a quick comparison `cherry-pick` vs `merge` vs `rebase`

Command	What it Does	When to Use
`git cherry-pick`	Apply specific commits to current branch	You want only certain commits, not the full branch
`git merge`	Combine entire branch history into current branch	You want to bring all commits and preserve history
`git rebase`	Move/Replay commits onto another base branch	You want a clean, linear history, avoid merge commits

TL;DR:

Use cherry-pick for precision, specific commits only
Use merge to combine full branch history
Use rebase to clean history and avoid unnecessary merges

Why You Might Need `cherry-pick`

You committed on the wrong branch (happens more than we admit)
You need a bug fix from one branch to another
You want to copy only certain commits, not merge everything
You made changes, reverted them locally, but commits got mixed up

My Real-Time Scenario: How I Discovered `cherry-pick`

Let me share how I personally ran into this:

I made some changes in a branch (let's call it branch A) but accidentally reverted the commits locally, leaving them in the unstaged area. Later, I re-committed those changes — but this time, I was working on branch B, where I only wanted my latest changes, not the leftover ones from branch A.

I pushed the branch to GitHub, went to open the PR, and BOOM — I saw two commits:

One commit with my intended change for branch B
But another unintended commit sneakily came from branch A

Total mess, right? But no worries — I fixed this cleanly using git cherry-pick.

I removed the wrong commit from branch B, stayed on branch A, cherry-picked only the commit I actually needed onto branch B, and pushed it again. Clean history, problem solved.

Step-by-Step Practical Guide to `git cherry-pick`

1. View Commit History with `git log`

git log --oneline --graph --all

✅ This shows a simple, visual commit history across all branches.

Tip: If you're working on a shared repository with your team and didn't create your own branch yet, you can check history of a specific branch like:

git log <branch-name> --oneline --graph --all

Example:

git log main --oneline --graph --all

✅ Use this to find the commit hash (abc123) you want to cherry-pick.

✅ Copy that hash — you'll need it in the next step.

2. Switch to Your Target Branch

Before you apply the commit, make sure you're on the correct branch:

git status

This shows your current branch.

If unsure, list all branches:

git branch

Switch to your target branch:

git checkout <your-branch-name>

Example:

git checkout feature/login

3. Cherry-Pick the Commit

git cherry-pick <commit-hash>

✅ This applies only the specific commit to your current branch, without merging the entire source branch or bringing unrelated changes.

Example:

git cherry-pick abcd1234

If the commit applies cleanly, you're done. If there's a conflict, Git will pause and you resolve it manually.

Cherry-Pick Multiple Commits

One by one:

git cherry-pick <commit1> <commit2>

Range of commits:

git cherry-pick commitA^..commitB

Handling Conflicts During Cherry-Pick

Conflict? No stress. Git pauses:

CONFLICT (content): Merge conflict in file.js

Resolve it:

git add .
git cherry-pick --continue

Or abort:

git cherry-pick --abort

You can also follow this short youtube video if you want:

Final Thoughts

Mistakes happen — commits go to the wrong place, branches get mixed up.

git cherry-pick is the clean, targeted way to:

✅ Move specific commits

✅ Fix accidental commits

✅ Avoid messy merges

Once you try it practically, you’ll use it confidently — like I did when I accidentally messed up branches.

Thanks for reading guys…

Managing Multiple GitHub/Git Accounts on One Machine (Personal + Work)

Suraj — Tue, 17 Jun 2025 13:14:04 +0000

As developers and DevOps engineers, it's common to contribute to both personal and professional projects. However, using two GitHub accounts on a single machine can lead to identity conflicts, unverified commits, or accidentally pushing to the wrong repository.

In this guide I’ll walks you through setting up two GitHub accounts securely, cleanly, and with verified SSH-signed commits all on a single machine.

Objectives

Work with both personal and work GitHub repositories (public & private).
Use two separate GitHub accounts on one machine.
Ensure verified commits via SSH commit signing.
Maintain a scalable, secure, and professional Git setup.

Step 1: Generate Separate SSH Keys

Create separate SSH key pairs for each GitHub account:

You can name these according to your preferences while generating the SSH keys

for-personal
for-work

# Personal Key
ssh-keygen -t ed25519 -C "you.email@gmail.com" -f ~/.ssh/for-personal

# Work Key
ssh-keygen -t ed25519 -C "you.workemail@gmail.com" -f ~/.ssh/for-work

Do not overwrite the default id_ed25519. Keeping keys separate ensures flexibility and security.

Step 2: Add Keys to SSH Agent

# View loaded keys
ssh-add -l

# Add new keys
ssh-add ~/.ssh/for-personal
ssh-add ~/.ssh/for-work

# Remove all existing keys (optional reset)
ssh-add -D

Step 3: Configure SSH `config` File

Create or edit your SSH config file:

touch ~/.ssh/config

Add the following content:

# Global settings
Host *
  AddKeysToAgent yes
  UseKeychain yes
  IdentitiesOnly yes
  ServerAliveInterval 60
  ServerAliveCountMax 3

# Personal GitHub
Host personal.github.com
  HostName github.com
  User git
  IdentityFile ~/.ssh/for-personal

# Work GitHub
Host work.github.com
  HostName github.com
  User git
  IdentityFile ~/.ssh/for-work

Step 4: Add Public Keys to GitHub

Upload the corresponding .pub files to each account:

~/.ssh/for-personal.pub → Personal GitHub
~/.ssh/for-work.pub → Work GitHub

GitHub → Settings → SSH and GPG Keys → New SSH Key

Step 5: Clone Repositories Using SSH Host Aliases

# Clone personal repo
git clone git@personal.github.com:your-username/my-repo.git

# Clone work repo
git clone git@work.github.com:my-org/work-repo.git

Step 6: Configure Git Identity per Repository

Set identity locally inside each project to avoid global conflicts:

# Inside Personal Repo
cd ~/PersonalRepo

git config user.name "your name"
git config user.email "your email"

# Inside Work Repo
cd ~/WorkRepo

git config user.name "your name"
git config user.email "your work email"

Step 7: Enable Verified Commits with SSH Signing

GitHub supports SSH-based commit signing, separate from SSH authentication.

Generate Signing Keys

# Personal Signing Key
ssh-keygen -t ed25519 -f ~/.ssh/id_ed25519_signing_personal -C "signing-personal"

# Work Signing Key
ssh-keygen -t ed25519 -f ~/.ssh/id_ed25519_signing_work -C "signing-work"

Add Signing Keys to GitHub

Go to GitHub → Settings → SSH and GPG Keys → New Signing Key and paste the contents of each .pub file.

Step 8: Configure Git to Use Signing Keys

Set up commit signing in each repo:

# Personal Repo
cd ~/PersonalRepo

git config commit.gpgsign true
git config gpg.format ssh
git config user.signingkey ~/.ssh/id_ed25519_signing_personal.pub

# Work Repo
cd ~/WorkRepo

git config commit.gpgsign true
git config gpg.format ssh
git config user.signingkey ~/.ssh/id_ed25519_signing_work.pub

Pre-Commit Workflow: Start SSH Agent and Test Connections

Before making commits in any repository, ensure your SSH agent is running and keys are loaded:

# Ensure SSH agent is running and keys are loaded
eval "$(ssh-agent -s)"
ssh-add ~/.ssh/personal_github
ssh-add ~/.ssh/work_github

# Test connections to verify which account will be used
ssh -T git@personal.github.com
# or
ssh -T git@work.github.com

# Now proceed with your git operations
git add .
git commit -m "Your commit message"
git push origin main

Successful messages like Hi broh! You've successfully authenticated confirm proper setup.

Note: This step is particularly important after system restarts or when opening new terminal sessions, as the SSH agent may not be running or may not have your keys loaded.

Final Result

Secure and clean GitHub SSH setup for both accounts.
Verified commits using SSH signing keys.
Separate identities per project.

Bonus Tip

To view signed commits:

git log --show-signature

The end! - Thanks for reading…

Automating The Deployment Spring Boot Deployment with AWS

Suraj — Wed, 28 May 2025 08:15:54 +0000

In this comprehensive guide, I’ll walk through setting up a complete CI/CD pipeline using AWS CodePipeline to deploy a Spring Boot application to Elastic Beanstalk. Here's what we'll cover:

Tools Used

Tool	Role
CodeCommit	Git repository for source code
CodeBuild	Builds the Spring Boot app and outputs the `.jar`
CodePipeline	Orchestrates source → build → deploy stages
Elastic Beanstalk	Deployment environment

Let’s understand the architecture diagram

Source (GitHub Repository)
- The pipeline starts when a code change is pushed (commit) to your GitHub repository.
- This event triggers the pipeline automatically — no manual deployment needed.
Build Phase (CodePipeline + CodeBuild)
- AWS CodePipeline detects the commit and initiates the CI/CD process.
- It hands over the code to AWS CodeBuild, which:
  - Builds the project (compiles the Spring Boot application).
  - Runs tests (unit/integration).
  - Returns the build status (success or failure) back to CodePipeline.
Deploy Phase (Elastic Beanstalk)
- If the build is successful, CodePipeline proceeds to the Deploy stage.
- It deploys the built Spring Boot application to AWS Elastic Beanstalk, a managed environment that handles infrastructure, load balancing, scaling, and app hosting.

Step-by-Step Follow-up:

Step 1: Repository Setup

First, create a GitHub repository for your Spring Boot project. This will serve as our source code repository.

GitHub Repository: https://github.com/Suraj-kumar00/aws-springboot-ecommerce

Step 2: Elastic Beanstalk Configuration

Create your Elastic Beanstalk environment with these configurations:

Give it the Application name And the Domain Name and also check the availability.

Select Java 17 as the platform

Upload your initial .jar file and set version to 1

Configure service access settings:
- Set up service role
- Configure EC2 key pair
- Set up AWS Elastic Beanstalk profile

In initial case there’s no EC2 instance profile so just click on the view permission details and create the role according to that in AWS IAM Role .

Step 3: Database Configuration

Choose the:

VPC ( In my case I’m choosing default)
Choose Instance subnets
Choose Database subnets

For the database setup:

Enable the RDS database integration
Configure database username
Set secure database password

After that just click on next.

Now in this step just choose the Security Group and we can edit it lated in the EC2 security group inbound rule for opening the custom ports:

Other then that leave all the settings defalut and go to the next step.

Now choose the system as Basic:

And leave all the setting as it is but change the ENVIRONMENT VARIABLES :

After that click on the next step.

At the last step just review all the configuration and submit it.

Step 4: Pipeline Setup

Create your AWS CodePipeline:

Navigate to AWS CodePipeline and create a new pipeline

Now chose the Custom build pipeline

Now give the pipeline a name and leave all the setting default and click on the next.

Now Select the provider which GitHub in my case using OAuth.

After Authenticating chose the Repository name and the branch and click on next.

Now select the Other build providers and create a new project:

Give the project name:

After that chose the buildspec.yml options and click on the create code pipeline.

After that choose it will redirect you to the same page and just click on the next step:

Now the in the test stage choose the provder AWS CodeBuild and the project name and continute:

Now in the deploy stage choose the provider as AWS Elastic Beanstalk ,

Region, Application Name and the Environment Name.

Essential Configuration Files

Add this buildspec.yml to your project root:

You should change the .jar because you name could be different.

version: 0.2
phases:
  install:
    runtime-versions:
      java: corretto17
  pre_build:
    commands:
      - echo Build started on `date`
  build:
    commands:
      - mvn clean install
artifacts:
  files:
    - target/Shopping_Cart-0.0.1-SNAPSHOT.jar
    - Procfile
    - .ebextensions/**/*
  discard-paths: no

5. Pipeline Execution Flow Diagram

This is the execution result of the AWS Code Pipeline Taking the source, Building it and Deploying the new verion of the application to AWS Elastic Beanstalk .

6. Result:

The Application was deploy on this URL: http://aws-springboot-ecommerce.ap-south-1.elasticbeanstalk.com/ (This will not work now as I deleted the steup)

7. Common Challenges and Solutions

Database Connection Issues:

Problem: Build failures due to communication link issues
Solution: Implement H2 in-memory database for testing

JAR File Naming:

Problem: Deployment failures due to JAR file mismatches
Solution: Maintain consistent artifactId naming across configurations

Best Practices

Key practices to follow:

Separate test and production configurations
Use environment variables for sensitive data
Implement proper proxy configuration
Add post-deployment hooks
Maintain consistent artifact naming
Implement proper error handling and logging

Thanks for reading - See you in the next one!

Deploying SpringBoot Application on AWS EC2: A Comprehensive Guide

Suraj — Wed, 21 May 2025 11:46:45 +0000

Introduction

This guide outlines the process of deploying a SpringBoot application on AWS EC2 with GitHub Actions for automated deployment. The setup includes Docker containers and proper security configurations.

Prerequisites

AWS Account
GitHub Repository
Basic knowledge of Docker and AWS services
SpringBoot application ready for deployment

NOTE: While working on this project I have made the repository private, so remember

If your repo is private, then you must configure SSH or PAT on EC2 to interact with it.
If your repo is public, no key setup is needed to clone it.

But for your reference if you want the application I’m making it public

Here is the Repository

https://github.com/Suraj-kumar00/scm-springboot-application-devops

First let’s understand the architecture Diagram

Architecture Overview

User accesses the app via a web browser using the HTTP.
The request hits Nginx running on the EC2 instance, which listens on port 80.
Nginx acts as a reverse proxy and forwards the request to the Spring Boot application running inside a Docker container on port 8081.
The Spring Boot app processes the request and, if needed, communicates with the MySQL database (also running in a Docker container on the same EC2 instance).
The response is sent back through the same path:

MySQL → Spring Boot → Nginx → User's browser.
GitHub Actions is used to automatically deploy updates to the EC2 instance by SSHing in and running the necessary Docker commands (e.g., docker-compose up).

Step 1: Launch EC2 Instance

Begin by setting up your EC2 instance with these specifications:

Choose Ubuntu as the operating system
Select t2.medium instance type
Create and download a new key pair for SSH access
Configure security group with the following ports:
TCP 22 (SSH)
TCP 80 (HTTP for Nginx)
TCP 443 (HTTPS)
TCP 8081 (Spring Boot via Docker)
TCP 3000 (phpMyAdmin)
Set EBS volume size (20GB recommended for free tier)

Step 2: Configure Elastic IP

Navigate to Elastic IP section in AWS Console
Allocate new Elastic IP address
Associate it with your EC2 instance
Note down the Elastic IP for future use

Step 3: SSH Into EC2 Instance

ssh -i "your-key.pem" ubuntu@your-elastic-ip

Step 4: Install Docker and Docker Compose

Create and execute this installation script:

#!/bin/bash

# Install Docker
sudo apt update
sudo apt install docker.io -y
sudo systemctl enable docker
sudo usermod -aG docker $USER

# Install Docker Compose
sudo curl -L "<https://github.com/docker/compose/releases/latest/download/docker-compose-$>(uname -s)-$(uname -m)" \\
  -o /usr/local/bin/docker-compose
sudo chmod +x /usr/local/bin/docker-compose

Step 5: Set Up SSH for GitHub

Generate SSH key on EC2:

ssh-keygen -t rsa -b 4096 -C "ec2-rsa-key"

Add the public key to GitHub:
Copy the content of ~/.ssh/id_rsa.pub
Add it to GitHub under Settings > SSH and GPG Keys

Step 6: Clone and Deploy Application

git clone git@github.com:your-username/your-repo.git
cd your-repo
docker-compose up --build -d

Step 7: Configure Nginx as Reverse Proxy

Install and configure Nginx:

sudo apt install nginx -y
sudo nano /etc/nginx/sites-available/default

Add this configuration:

server {
    listen 80;
    server_name your-elastic-ip;

    location / {
        proxy_pass <http://localhost:8081>;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
    }
}

Restart Nginx:

sudo systemctl restart nginx

Step 8: Set Up GitHub Actions

Create .github/workflows/deploy.yml in your repository:

name: Deploy to EC2

on:
  push:
    branches:
      - main
  workflow_dispatch:

jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - name: Setup SSH Key
        run: |
          echo "${{ secrets.EC2_SSH_PRIVATE_KEY }}" > key.pem
          chmod 600 key.pem

      - name: Deploy via SSH
        run: |
          ssh -o StrictHostKeyChecking=no -i key.pem ${{ secrets.EC2_USER }}@${{ secrets.EC2_HOST }} << 'EOF'
            cd /home/ubuntu/your-repo
            git pull origin main
            docker-compose down
            docker-compose build --no-cache
            docker-compose up -d
          EOF

Step 9: Configure Auto-restart on Reboot

Set up a cron job:

crontab -e
# Add this line:
@reboot cd /home/ubuntu/your-repo && docker-compose up --build -d

Result!!

Common Challenges and Solutions

Permission Issues
- Docker permission denied: Run sudo usermod -aG docker $USER
- SSH key issues: Verify proper key permissions (chmod 600)
Networking Issues
- 502 Bad Gateway: Check if Spring Boot container is running
- Connection refused: Verify security group settings

Best Practices

Always use environment variables for sensitive data
Regularly backup your application data
Monitor application logs and performance
Keep Docker images updated with security patches
Use proper version tagging for Docker images

Thanks for reading - see you in the next one!

You Need to Learn Docker Right Now! (Part 1)

Suraj — Tue, 25 Mar 2025 13:21:46 +0000

Let’s Understand the Problem

Let's say a developer is working on a project and has set up all the required dependencies and configurations. Everything works fine. However, when a team collaborates on the same project across different operating systems, they may have different dependencies and setups, making it a hassle to configure the environment repeatedly.

For example, if a tool is built for Windows, it won’t run on macOS or Linux, making setup even more difficult. Managing multiple environments and ensuring consistency becomes a challenge.

Docker solves this problem by creating a standardized, portable environment that works the same across all systems, eliminating compatibility issues and simplifying setup.

Before Docker:

Each application required a dedicated server.
Running multiple applications on the same server was difficult due to conflicts between dependencies and configurations.
Companies had to invest in more servers and powerful CPUs, leading to high costs and inefficient resource utilization.
This approach was not scalable, cost-effective, or environmentally friendly.

Who Solved This Problem?

Virtual Machines (VMs) provided a solution by allowing multiple applications to run on the same physical server.
This was an improvement but still had limitations.

Problems with Virtual Machines:

Each VM required its own full operating system, consuming significant resources.
Managing dependencies across different environments was still complex.
“Works on my machine” issues persisted, making development and deployment inconsistent.

Then Containers Came into the Picture

Containers allow applications to run without needing multiple OS installations.
Docker simplified containerization, making it easier to build, share, and deploy applications.
Containers are lightweight, fast, and portable across environments.
Better resource utilization, run more apps on the same hardware.
Quick to build, destroy, and deploy, ideal for cloud scaling.
Standardized workflow from development to production.

Difference between Virtual Machine & Containers

1. Virtual Machines (VMs)

Each VM runs on a Hypervisor, which allows multiple VMs to share the same physical infrastructure.
Every VM has its own Guest OS, making it heavyweight since each OS requires its own resources (RAM, CPU, Storage).
Applications inside VMs come with their own dependencies (Bins/Libs), which can lead to duplication of resources.
Overhead: Since each VM has a separate OS, it consumes more CPU and memory, making it less efficient for running multiple applications.

2. Containers

Containers share the same Host OS but are managed by a Container Engine (e.g., Docker, CRI-O, etc.), eliminating the need for separate Guest OS instances.
Each container has its own dependencies (Bins/Libs) but shares the OS kernel with other containers, making them lightweight and efficient.
Faster startup and lower overhead compared to VMs since containers don’t require a full OS boot.
Ideal for microservices and scalable applications since they consume fewer resources and can be deployed rapidly.

Key differences in short:

Feature	Virtual Machines (VMs)	Containers
OS Overhead	Each VM has a full Guest OS	Share the same Host OS
Startup Time	Slower (OS boot required)	Faster (lightweight)
Resource Usage	Heavy (CPU & RAM overhead)	Efficient & lightweight
Scalability	Harder to scale due to overhead	Easily scalable
Isolation	Stronger (Separate OS per VM)	Process-level isolation
Performance	Slower due to OS duplication	Faster & optimized

What is Docker?

Docker is a containerization platform that simplifies the process of building, shipping, and running applications in isolated environments called containers. Under the hood, Docker utilizes Linux namespaces and cgroups to create lightweight, portable containers. Initially, Docker used LXC (Linux Containers), but later switched to its own container runtime called containerd

According to Docker’s official site:

Docker is an open platform for developing, shipping, and running applications. It allows developers to package software into standardized units called containers, which include everything needed to run: libraries, system tools, code, and runtime.

Why Docker?

Manages Containers Easily – It provides tooling to handle containers efficiently.
Simplifies Deployment – Packages an app and its dependencies into a single unit (Docker container).
Build Once, Run Anywhere – Ensures consistency across development, testing, and production.
Fast & Lightweight – Containers are quick to create, destroy, and scale.

Installation of Docker

I have listed the official website to install the Docker Engine and Docker Desktop for up to date installation steps.

Official Documentation for Installation(Check according to your device)

Website: Install Docker Desktop

Website: Install Docker Engine

Docker Daemon:

The Docker Daemon (dockerd) is the core engine that runs in the background. It listens for Docker API requests and manages Docker objects such as images, containers, networks, and volumes. The daemon handles all the container operations like starting, stopping, and scaling containers, as well as pulling and creating images.

Docker Desktop:

Docker Desktop is an application for MacOS and Windows that provides a GUI for managing Docker environments. It includes Docker Engine, Docker CLI client, Docker Compose, Kubernetes, and a graphical user interface that allows users to manage containers, images, and other Docker resources visually. Docker Desktop simplifies the process of setting up and using Docker on your local machine.

How Docker Works?

Docker follows a simple process to create, distribute, and run containers. Here’s how it works step by step:

Docker Architecture

1. Docker Client

The developer interacts with Docker using commands like:

docker build → Creates a Docker Image from a Dockerfile.
docker pull → Downloads an existing image from the Docker Registry (like Docker Hub).
docker run → Creates and starts a container from an image.

2. Docker Daemon

The Docker Daemon runs in the background and manages everything, including images, containers, networks, and storage.
It processes the client commands and does the actual work of building, pulling, and running containers.

3. Docker Host

The Docker Host is where containers run.
It holds two key components:
- Images: Pre-built packages that contain applications and dependencies (e.g., Ubuntu, Nginx).
- Containers: Running instances of Docker images that execute applications.

4. Docker Registry

This is a storage location for Docker images like you store you code on GitHub.
Common registries include Docker Hub, Google Artifact Registry,Azure container registry, Amazon Elastic Container Registry (ECR), GitHub Conainer registry(GCR) and private registries.
Images can be pulled (docker pull) from here or pushed (docker push) to share with others.

Process Flow

Step 1: You build an image using docker build .

Step 2: If the image isn’t available locally, Docker pulls it from the registry using docker pull.

Step 3: You run a container using docker run, which creates an instance from the image.

What is a Dockerfile?

A Dockerfile is a script containing a set of instructions to build a Docker Image. It defines the base OS, dependencies, and commands required to set up an environment.

Docker Image

A Docker Image is a lightweight, standalone, and executable software package that includes everything needed to run an application: code, runtime, system tools, libraries, and dependencies. A docker image is built in layers, where each instruction in the Dockerfile creates a new layer. These layers stack on top of each other to form the final image.

FROM → Base image layer (e.g., Ubuntu, Node.js, or Alpine).
WORKDIR → Sets the working directory inside the container.
COPY → Copies files from the host to the container.
RUN → Executes commands inside the image (e.g., installing dependencies).
EXPOSE → Declares which ports the container will use.
CMD / ENTRYPOINT → Defines the default command when the container starts.

Each layer is immutable—once created, it doesn’t change. Instead, new layers are added when modifications are made.

Images are immutable (cannot be changed).
Stored locally or on Docker Hub for sharing.

Writing your first Dockerfile:

FROM ubuntu:latest

WORKDIR /app

COPY package.json package-lock.json ./

COPY . .

EXPOSE 3000

CMD ["npm", "start"]

Docker Layer Caching

Docker optimizes image builds by caching layers. If a layer hasn’t changed, Docker reuses the cached version instead of rebuilding it.

How caching works:

Docker runs through the Dockerfile line by line.
If a layer hasn’t changed, it is pulled from cache.
If a layer changes, all layers after it must be rebuilt.

Containers

A Docker Container is a running instance of an image. It provides a lightweight and isolated environment to run applications.

Ephemeral (data is lost when deleted unless using volumes).
Multiple containers can be created from the same image.

Recap with Demo: Dockerizing a Nodejs application

Remember above we have written our first Dockerfile we will be using that.

Now for the practice at your own you can use this github repository, here you will find the nodejs applicaiton code okay: Nodejs Application Code

Dockerfile

Step 1: Writing the Dockerfile

# Use the latest Ubuntu image as the base
FROM ubuntu:latest

# Set the working directory inside the container
WORKDIR /app

# Copy package files first (helps with caching layers efficiently)
COPY package.json package-lock.json ./

# Install dependencies
RUN apt update && apt install -y nodejs npm && npm install

# Copy all remaining project files
COPY . .

# Expose port 3000 to allow external access to the application
EXPOSE 3000

# Start the application using npm
CMD ["npm", "start"]

Step 2: Build the Docker Image

Now, let's build the image using the Dockerfile:

docker build -t mynodeapp .

t mynodeapp → Gives the name mynodeapp to the image.
. → Refers to the current directory where the Dockerfile is located.

Step 3: Run the Container

Once the image is built, we can start a container from it:

docker run -d -p 3000:3000 --name mynodejscontainer mynodeapp

d → Runs the container in detached mode (in the background).
p 3000:3000 → Maps port 3000 of the container to port 3000 of the host.
name mynodejscontainer → Names the running container mynodejscontainer.
mynodeapp → Uses the mynodeapp image to create the container.

Step 4: Verify the Running Container

To check if the container is running:

docker ps

CONTAINER ID   IMAGE       COMMAND        STATUS        PORTS                  NAMES
abcdef123456   mynodeapp   "npm start"    Up 5 minutes  0.0.0.0:3000->3000/tcp  mynodejscontainer

Step 5: View Logs of the Application

To check logs and ensure the app is running properly:

docker logs -f mycontainer

> mynodeapp@1.0.0 start /
> node server.js
Server is running on port 3000...

Step 6: Access the Application

Now, open your browser and go to:

http://localhost:3000

Now, we have successfully dockerized our Node.js application running inside a Docker container!

This is the flow form writing a dockerfile, building the image out of it and running the container of the image.

Basic Docker Commands

Run a container interactively

# Runs an Ubuntu container in interactive mode (-it)
docker run -it ubuntu

# Run the container using port you have exposed in dockerfile, for example -p (publish)
docker run -it -p hostPort:containerPort <name-of-the-image>

List all running containers

# Shows currently running container
docker container ls

# or
docker ps

List all containers (including stopped ones)

# Lists all containers, including stopped ones
docker container ls -a

Stop a running container

# Stops a running container using its container ID
docker container stop [container_id]

Remove all stopped containers, unused volumes, and networks

# Cleans up unused containers, networks, and images
docker system prune

Exec into the running container

docker exec -it <name-of-your-container> bash

Inspect running processes in a container

# Lists all running processes inside the container after you exec into the container
ps -ef

Image & Container Management

List all Docker images

# Shows all locally available Docker images
docker images

Pull an image from Docker Hub

# Downloads the latest Nginx image
docker pull nginx

Remove an image

# Deletes the specified Docker image
docker rmi nginx

Start a stopped container

# Restarts a stopped container
docker start [container_id]

# Or you can use the name of the container as well
docker start <name-of-the-conatiner>

Restart a container

# Stops and starts a container again
docker restart [container_id]

# Or you can use the name of the container as well
docker restart <name-of-the-conatiner>

Delete a container

# Removes a stopped container permanently
docker rm [container_id]

# Or you can use the name of the container as well
docker rm <name-of-the-conatiner>

Container Logs & Inspection

View container logs

# Shows logs of a specific container
docker logs [container_id]

# Or you can use the name of the container as well
docker logs <name-of-the-conatiner>

Check container details

# Displays detailed information about a container
docker inspect [container_id]

# Or you can use the name of the container as well
docker inspect <name-of-the-conatiner>

Monitor real-time container stats

# Shows real-time CPU, memory, and network stats of containers
docker stats

I’ll be covering these advanced and Important topics in next blog

Docker Compose
Docker Networking
Docker Volumes
Docker Swarm
Docker Vs Kubernetes

The End!

I hope you enjoyed this blog and have learned about docker today. See you in the next one.

Building a Secure, Fast & Scalable Static Website on AWS - MindfulCloud

Suraj — Sat, 15 Mar 2025 06:38:29 +0000

Introduction

The Problem It Solves

Anyone can host a static website on AWS, but that’s not enough in today's landscape. The real challenge is building a secure, fast, and scalable website that efficiently uses AWS resources.

Security Risks: Hackers are everywhere, and a simple HTML file won’t stop them.
Performance Issues: Users expect lightning-fast websites. Anything over a second and they bounce.
Cost Management: Resources need to be allocated smartly to avoid unnecessary spending.

This blog walks you through building a highly secure, performance-optimized static website leveraging AWS services.

How I Built It

The AWS services used:

AWS S3: Foundation for static site storage.
CloudFront: Distributes content worldwide for ultra-fast loading.
Certificate Manager: Manages HTTPS encryption.
AWS WAF: Protects against cyber threats like DDoS, XSS, and SQL Injection.
CloudWatch: Monitors traffic, security, and performance with alerts.
AWS Route 53: Manages the custom domain.

This is the architecture for Hosting a Static Website

Understanding the Architecture: The Complete Flow

1️⃣ User Request (Entry Point)

A user visits https://mindfulcloud.devsuraj.me.
The request is sent to Amazon Route 53, which maps the domain to CloudFront.

2️⃣ Route 53 → CloudFront

Route 53 forwards the request to Amazon CloudFront (CDN).
CloudFront serves cached content to it’s edge locations near to the users for lower latency.

3️⃣ Security Layer

AWS WAF protects against:
- SQL Injection
- Cross-site Scripting (XSS)
- DDoS attacks
AWS ACM (AWS Certificate Manager) enables SSL/TLS encryption.

4️⃣ Fetching Content from S3

If CloudFront doesn’t have the content cached, it fetches it from Amazon S3.
S3 acts as the origin server for static assets like HTML, CSS, JavaScript, and images.

5️⃣ Monitoring & Logging

AWS CloudWatch tracks:
- CloudFront request logs, cache hit ratio, and performance metrics.
- S3 storage access patterns.
Alerts notify about security threats or traffic spikes.

Implementation

Step 1: Setting Up an S3 Bucket for Static Website Hosting

Go to AWS Console S3 service and Create Bucket.
Enter a unique bucket name (e.g., mindfulcloud.devsuraj.me).
Choose public or private access (public if hosting static content).
Enable static website hosting under Properties.

Scroll down below and enter the Index document and save it.
Upload your static website files (HTML, CSS, JS).

Step 2: Configuring AWS ACM (SSL Certificate) for HTTPS

Go to AWS Certificate Manager (ACM) → Request a Certificate.

You should create the certificate in the N.Verginia otherwise you’ll not be able to see it when you select the certificate in the cloudfront.
Choose Public Certificate → Enter domain name (e.g., mindfulcloud.devsuraj.me).

In my case I have my root domain which devsuraj.me so I want subdomain to attach it and above I have mentioned.
Choose DNS validation (faster & recommended).
ACM provides CNAME records; add them to your Namecheap DNS settings.

Copy the CNAME name and CNAME value.

Add it to the DNS service provide you have in my case I have Namecheap:
1. After login to you namecheap to domain list and click on manage and go to the advanced DNS.
2. Now create new record
3. Enter the CNAME and The Value
Now you’re done with ACM, wait for validation (may take a few minutes to hours).

Step 3: Setting Up a Route 53 Hosted Zone

Go to AWS Route 53 → Create Hosted Zone.
Enter your subdomain (e.g., mindfulcloud.devsuraj.me).
Copy the provided NS (Name Server) records and update them in Namecheap’s DNS settings.
Create an A record (alias) pointing to CloudFront Distribution.

Step 4: Setting Up CloudFront for CDN & Caching

Go to AWS CloudFront → Create Distribution.
Set Origin Domain as your S3 bucket.
Enable HTTPS using your ACM certificate.

Select you ACM certificate:
Configure default root object (index.html).
Deploy the distribution and note the CloudFront URL.
After creating the distribution it you’ll give you the bucket policy to you just copy that and paste it in the bucket you created:

Step 5: Connecting Namecheap Domain to AWS

1️⃣ Go to Namecheap DNS Settings

2️⃣ Verify NS Records are correct( as we did this in step 3)

Ensure Nameservers are set to Custom DNS with Route 53 NS records.

3️⃣ Save & Wait for Propagation

Click Save Changes → Wait a few minutes to 24 hours.
Open https://yourdomain.com in a browser to confirm it works.

Step 6: Enhancing Security with AWS WAF

Go to AWS WAF → Create WebACL.
Attach it to CloudFront Distribution.
Add security rules:
- Block common threats (DDoS, SQL Injection, XSS attacks).
- Rate limiting for excessive requests.
- Geo-restriction to block traffic from unwanted locations.
Enable AWS WAF logging to monitor security threats.

Step 7: Enabling CloudWatch Monitoring & Logging

Enable CloudFront Logging:
- Go to CloudFront → Enable Standard Logging.
- Choose an S3 bucket to store logs.
Create CloudWatch Dashboards:
- Monitor requests, latency, cache hit ratio.
- Set up CloudWatch alarms for security events.
Set Up Alerts:
- Use AWS SNS (Simple Notification Service) to receive alerts via email/SMS.
- Example: Alert if CloudFront request count exceeds a threshold.
Select The SNS topic or create one:
And just complete the step 3 and step 4 in creating the alarm and you’re good go.

Step 8: Implementing Reliability & Disaster Recovery

Enable S3 Versioning:
- Go to S3 → Properties → Enable Versioning.
- This helps rollback in case of accidental file deletion.
Enable Cross-Region Replication:
- Go to S3 → Replication Rules → Set up a backup region.
- Choose a different AWS region for redundancy.

Send the requests to your website to check the performance, WAF security and other metrics.

#!/bin/bash

URL="your website url"
REQUESTS='' # include the number of requrests you want to send

echo "Starting load test on $URL with $REQUESTS requests..."

for ((i=1; i<=REQUESTS; i++))
do
  curl -s -o /dev/null -w "Request $i: HTTP %{http_code}\n" $URL &
done

echo "Load test initiated!"

How to Run

Save this script as simple_load_[test.sh](http://test.sh/).
Give it execution permission:

chmod +x simple_load_test.sh

Run it:

./simple_load_test.sh

The end!!!

Thanks for the reading guys, see you in the next one…

Build & Package Manager tools in DevOps

Suraj — Mon, 10 Mar 2025 06:49:14 +0000

Introduction to Build & Package Manager Tools:

What are built and package manager tools?

When developers create an application, it needs to be available to end users. This involves deploying the application on a production server, which requires moving the application code and its dependencies to the server. This is where build and package manager tools come into play.

Package application into a single movable file
And this single movable file is called an artifact.
Packaging = “building the code”
Building the code involves:
- Compiling (Hundreds of files into 1 single file)
- Compress (Hundreds of files into 1 single file)
- After the artifact was built we kept artifacts in storage also
- In case we need to deploy multiple times, have a backup, etc.
  
  E.g.: If we deploy the artifact on the dev server, we deploy the test environment, or later on the production environment.

Artifact repository:

The storage location where we keep the artifact once we build it is called the artifact repository, an example is Nexus, JFrogArtifactory.

What kind of file is in the artifact?

The artifact file looks different for each programming language
E.g., if you have a Java Application the artifact file will be a JAR or WAR file
JAR = Java Archive
These include whole code and dependencies like:
- Spring Framework
- datetime libraries
- Pdf processing libraries

Install Java and Build tools

Install java
Install Maven
install Node + npm
Download IntelliJ or VSCode

How to build the artifact with dependencies?

Using a Build Tool, so there are special tools to build the artifact
These tools are specific to the programming language
For Java:
- There is Maven and Gradle
For NodeJs Or JavaScritp
- There are npm and yarn
What These tools do:
- Install dependencies
- Compile and compress your code
- And can do some other different tasks

Build tools in Java

JAR or WAR file
Maven: Uses XML for configuration and is widely used for managing dependencies and building projects.
Gradle: Uses Groovy for configuration and is known for its flexibility and performance.

Tools	Maven	Gradle
Language uses	XML	Groovy

Which is more convenient for scripting and writing all those tasks for building the code or compiling etc.
Both have command line tools and commands to execute the tasks

Gradle commands to execute the Java file (Doing Hands-On)

This command will compile the code, resolve dependencies, and package the application into an artifact using Gradle.

./gradlew build

In the Gradle, we don’t need to configure how the JAR file is built.

Maven command to execute the Java file

Add this plugin to your pom.xml file:

<build>
  <plugins>
    <plugin>
      <groupId>org.springframework.boot</groupId>
      <artifactId>spring-boot-maven-plugin</artifactId>
      <version><!-- Specify version here --></version>
      <executions>
        <execution>
            <goals>
               <goal>repackage</goal>
            </goals>
        </execution>
      </executions>
    </plugin>
  </plugins>
</build>

The command will compile the code, run tests, package the application into an artifact, and install it into the local Maven repository.

mvn install

Build Tools for Development (Managing Dependencies)

It would help if you had the build tools also locally when developing the App
Because you need to run the app locally
run tests

Maven and Gradle have their own dependency files

Dependencies file = Managing the dependencies for the project

Where these Dependencies files lies:

For the maven its - pom.xml
For the Gradle it's - build.gradle

You need a library to connect your Java application to ElasticSearch

Find a dependency with name and version
You add it to the dependencies file (e.g. pom.xml)
Dependency gets downloaded locally (e.g local maven repo)

Run the application

Now let’s say we’ve built an artifact, stored it in the artifact repository, and copied it also on the server.

Now the question is how do you run the application with the artifact

This is the command to execute the .jar file for example:

// This example is for gradle
java -jar <name of jar file>

//This is an example of Gradle
java -jar build/libs/java-app-1.0-SNAPSHOT.jar

// This example is for Maven
java -jar <name of jar file>

//This is an example of Maven
java -jar target/java-maven-app-1.0-SNAPSHOT.jar

So if you are on a fresh server where and you have Java installed you can download the artifact from the repository and start the application using above commands.

Build JavaScript application

What about the JavaScrip Application

JS doesn’t have a special artifact type
So it can’t be built in ZIP or TAR file

So how do we build a js artifact file as a zip or tar file

These are the alternatives over Gradle and Maven in JavaScript

npm - much more widely used
yarn

These both contain package.json file for dependencies

npm and yarn are package managers and NOT build tools

These package managers install dependencies, but not used for transpiling JavaScript code or JavaScript artifact.

npm repository for dependencies : It refers to the npm registry, which is a public repository of JavaScript packages. It is used to find and install dependencies (libraries or modules) required for JavaScript projects.

Command Line Tools - npm

npm start - start the application
npm stop - stop the application
npm test - run the test
npm publish - publish the artifact

What does the zip/tar file include?

application code, but not the dependencies

When you Run the app on the server

You must install the dependencies first
Unpack zip/tar
Run the app

You need to copy the artifact & package.json file to the server to run the application

To create an artifact file from our node js application

npm pack

JavaScript world is much more flexible than the Java world
But not as structured and standardized

So the above is about nodejs a backed application but what about frontend application when it comes to package.

Package Frontend Code

Different ways to package this

Package fronted and backend code separately
Common artifact file

For example, if we have reactjs and nodejs application both in Javascript than we can have:

Separate pakcage.json file for frontend and backend
Common package.json file
Frontend/react code needs to be transpiled!
Browser don’t support latest JS versions or other fancy code decorations, like JSX
The code needs to be compressed/minified!
Separate tools for that - Build Tools/Bundler!

e.g.: webpack

Build Tools - Webpack

Webpack is a build tool that bundles, transpiles, and minifies JavaScript and other assets for frontend applications.

It will transpiles, minified, bundles, compresses the code.

// install the webpack
npm install

// It is used to bundle or compress the javascript code
npm run build

Dependencies for Frontend Code

npm and yarn for dependencies
Separate package.json vs. common package.json with backend code
Can be an advantage to have the same build and package management tools

In case react has Java as a backend:

Bundle-fronted app with webpack
manage dependencies with npm or yarn
package everything into a WAR file

What are Build tools for other programming languages

These concepts are similar to other languages
pip package manager for python

Publish an artifact into the repository

You build the artifact you need to push it to the artifact repository

Build tools have commands for that
Then you can download (curl, get) it anywhere

NOTE: we don’t fetch or push the artifact like that because of Docker.

The two important things to understand related to these package managers and build tools that we use for different programming languages Docker and another CI/CS pipeline(Jenkins)

Build tools & Docker

With Docker, the need to create zip or tar files is reduced. Docker images can directly contain the application code, simplifying the deployment process.

With docker, we don't need to build and move different artifact types.
There is just one artifact type - Docker images
Now, we build Docker images from the application and we don't need a repository for each file type, no need to move multiple files to the server like package.json, no need to zip, just copy everything into the docker filesystem and run it from docker image.
Docker image is also an artifact
In order to start the application you don't need npm or java on the server, execute everything ( command to run the JAR or node application) inside the docker image.

NOTE: For the different Java and javascript applications - we don’t need to create zip or tar files anymore because of docker images because we can directly copy and paste the JS code files into docker image but we have to build the application

Docker file for Javascript

Docker file for java

Build Tools for DevOps Engineers

Why should you know these Build Tools?

DevOps engineers need to understand build tools to assist developers, automate builds, and manage CI/CD pipelines. This includes:

Developers install dependencies locally and run the application, but don’t build it locally
You need to execute tests on the build servers

npm/yarn test

gradle/mvn test
Help Developers for building the application
Because you know where and how it will run
Build Docker image ⇒ Push to Repo ⇒ Run on Server
You need to configure the build automation tool CI/Cd pipeline
Install dependencies ⇒ run tests ⇒ build/bundle app ⇒ push to repo

NOTE: You don’t run the app locally

You need to learn AWS right Now!

Suraj — Mon, 10 Mar 2025 06:39:00 +0000

Introduction

Amazon Web Services (AWS) is a cloud computing platform that offers a wide range of services such as computing power, storage, databases, and networking. If you're a beginner I’m here to help you with my experience of learning and building project in AWS infrastructure, AWS provides scalable and flexible solutions for building applications.

In this guide, we'll be exploring the fundamentals of AWS and walk through the setup of Identity and Access Management (IAM), which is essential for securing your AWS environment.

What is AWS?

AWS is a cloud computing service provided by Amazon that offers on-demand computing resources over the internet with pay-as-you-go pricing. It eliminates the need for physical hardware, reducing costs and increasing efficiency.

Key Features of AWS:

✅ Scalability – Automatically scales based on demand.

✅ Pay-as-you-go Pricing – No upfront costs; pay only for what you use.

✅ Security & Compliance – Built-in security measures and compliance with industry standards.

✅ Global Infrastructure – Data centers across multiple regions for high availability.

✅ Wide Range of Services – Compute, storage, databases, AI/ML, and more.

Popular AWS Services:

EC2 – Virtual machines for computing power.
S3 – Secure object storage.
RDS – Managed relational database service.
Lambda – Serverless computing.
VPC – Private cloud networking.

We’ll discuss most used AWS services in the Cloud/DevOps space in the next blog.

Create your AWS account now!

Prerequisites:

You’ll need a valid Email Address
A Payment Method (debit card for example) - don’t worry, broh 😂, they’re not here to swipe your cash!

Steps to Create an AWS Account:

My AWS Console:

Understanding IAM (Identity and Access Management)

AWS IAM is a security service that allows you to manage users, permissions, and access to AWS resources.

Why is IAM Important?

🔒 Access Control: Defines who can access AWS resources.

🔒 Least Privilege Principle: Assigns only the required permissions to users.

🔒 Multi-Factor Authentication (MFA): Enhances security with an additional authentication step.

🔒 AWS Root User Protection: Avoid using the root account for daily tasks.

IAM Components:

Users: Individual AWS accounts that have credentials (such as a username, password, or access keys). Each user represents a person or an application that interacts with AWS resources.
Groups: Collections of users that share the same set of permissions. This makes it easier to manage access controls for multiple users at once.
Roles: Entities that define a set of permissions for AWS services or external identities. Roles allow you to grant temporary access without having to share long-term credentials.
Policies: JSON-based documents that define permissions. They specify what actions are allowed or denied on which AWS resources. We can create custom policies which is the used according to use-case.

Example: A policy is a JSON document that specifies allowed or denied actions. For example, the S3ReadOnlyAccess policy grants read-only access to an S3 bucket.
```
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": "s3:GetObject",
      "Resource": "arn:aws:s3:::example-bucket/*"
    }
  ]
}
```

Setting Up IAM in AWS

IAM Dashboard:

Follow these steps to configure IAM for a secure AWS environment.

Step 1: Create an AWS IAM User

Log in to AWS Management Console using the root account.
Navigate to IAM → Click on Users.
Click Add user and specify the user details
Click Next → set Permissions, Choose the permission options and if you have created group you can attack to it.
Click Next → Add Tags (Optional).
Click Create User → Download credentials (.csv file).

Step 2: Create an IAM Group & Assign Policies

Go to IAM → Click on Groups.
Click Create Group → Enter Group Name.
Attach a predefined IAM policy (e.g., AdministratorAccess, ReadOnlyAccess).
Add Users to the group → Click Create Group.

Step 3: Enable MFA for Extra Security

Navigate to IAM Users → Select the User.
Click Security Credentials → Enable Multi-Factor Authentication (MFA).
Use an Authenticator App (Google Authenticator/AWS MFA) to scan the QR code.
Enter the generated MFA codes → Click Assign MFA.

Step 4: Use IAM Role for AWS Services

An IAM Role is an AWS identity with a set of permissions that determine what actions are allowed or denied. Unlike IAM users, roles do not have long-term credentials (passwords or access keys). Instead, they provide temporary security credentials to AWS services or external identities.

Go to IAM → Click Roles → Create Role.
Choose AWS Service (e.g., EC2, Lambda).
Attach a Policy (e.g., AmazonS3FullAccess).
Click Create Role.

Best Practices for AWS IAM Security

✅ Use IAM Users Instead of Root Account – The root account should be used only for account setup and billing.

✅ Follow the Principle of Least Privilege – Grant only necessary permissions.

✅ Enable MFA for All Users – Adds an extra layer of security.

✅ Rotate Access Keys Regularly – Prevents unauthorized access.

✅ Monitor IAM Activity with CloudTrail – Track API calls and security events.

✅ Use IAM Roles for Applications – Avoid hardcoding credentials in code.

The end!

Hey guys, thanks for the reading, I hope you have learned something valuable today via this blog. Let me know in the comment if you have any doubt or anything you want to say. I would love to reply.

95% Of Software Engineers Aren't Using This Simple Git Trick

Suraj — Tue, 18 Feb 2025 11:17:17 +0000

If you work with Git regularly, you know that git log can be overwhelming, displaying a long list of commit hashes, authors, dates, and messages in a cluttered format.

To make your logs more readable and visually appealing, you can create a custom Git alias:

alias glp='git log --pretty=format:"%C(yellow)%h%Creset - %C(green)%an%Creset, %ar : %s"'

What This Alias Does:

Instead of the default git log output, this alias presents commit history in a concise, color-coded format:

%h → Shows the short commit hash in yellow.
%an → Displays the author’s name in green.
%ar → Indicates the commit time relative to now (e.g., "2 hours ago" or "3 days ago").
%s → Displays the commit message.

Example Output:

Making the Alias Permanent

By default, the alias will only work in the current terminal session. Once you close the terminal, it will be lost. Follow these steps to make it permanent:

Step 1: Check Your Current Shell

Before adding the alias, check which shell you are using:

echo $SHELL

If the output is:

/bin/bash → You are using Bash.
/bin/zsh → You are using Zsh.

This is important because the alias should be added to the correct configuration file.

Step 2: Add the Alias to the Correct File

✅ For Bash Users:

Edit the ~/.bashrc file:

nano ~/.bashrc

Add the following line at the end of the file:

alias glp='git log --pretty=format:"%C(yellow)%h%Creset - %C(green)%an%Creset, %ar : %s"'

Save the file (CTRL + X, then Y, then Enter).

✅ For Zsh Users:

Edit the ~/.zshrc file:

nano ~/.zshrc

Add the alias at the end of the file:

alias glp='git log --pretty=format:"%C(yellow)%h%Creset - %C(green)%an%Creset, %ar : %s"'

Save the file (CTRL + X, then Y, then Enter).

Step 3: Apply the Changes

For Bash, run:

source ~/.bashrc

For Zsh, run:

source ~/.zshrc

Step 4: Test the Alias

Now, run:

glp

If the alias works, you’ll see a clean and structured Git log output.

What If the Alias Still Doesn't Work?

If you are using Bash and see errors like command not found: shopt, your ~/.bashrc file might be corrupted.

To fix it, reset your Bash configuration:

mv ~/.bashrc ~/.bashrc.bak  # Backup old file
cp /etc/skel/.bashrc ~/.bashrc  # Restore default bashrc
source ~/.bashrc

Then, re-add the alias and try again.

Why Use This?

Improved readability – No more overwhelming logs.
Quick insights – Easily see who made a commit and when.
Better debugging – Quickly locate specific changes.

By customizing your Git workflow with aliases like this, you can make working with Git much more efficient. 🚀

Try it out and streamline your Git experience!

Let's Learn Linux: Introduction

Suraj — Tue, 18 Feb 2025 08:19:55 +0000

Let's first understand what is Operating System(O.S):

An OS is system software that manages computer hardware and software resources and provides common services for computer programs.
In a nutshell, An OS is software that acts as a middleman or a bridge between c*omputer hardware and the computer user*. It provides a user interface and controls the computer hardware so that software can function.

Types of OS:

Desktop OS: Windows, macOS, Linux such as Ubuntu
Server OS: Windows server, Linux distributions like CentOs, Red Hat Enterprise Linux
Mobile OS: Android, iOS, Windows Mobile
Embedded OS: used in devices like routers, smart TVs, automobiles, home appliances, etc.
Real-Time OS: used in critical systems like medical equipment, car ECUs, aerospace, defense, network firewalls, home security systems, etc.

What is Linux:

It is a free and open-source OS, and it is:
- Secure
- Distributed
- Fast
Its open-source nature means that a community of developers and users contribute to its development.
It’s similar to Windows and macOS, but it’s different in several ways
Linux is very popular for its stability, security, and flexibility. It can be modified and distributed by anyone, which has led to many different versions, known as “distributions” and each distribution is tailored(for a particular purpose) for different users.

Why learn Linux or its importance:

Widely used in servers and cloud computing
corporate world uses Linux as their primary OS
Free software philosophy
Strong command line interface
Faster processing (because of CLI)
Enhanced security
Customization because of the open-source nature
Community support
Understanding of other OS
Career opportunities

Linus is a kernel-based Operating System:

What is the kernel: The core of the UNIX system. Kernel is the heart of your operating system because it establishes the communication between the hardware and the software.

Below is the Architecture:

Basically, kernel has four primary responsibilities:

Device managemant
Memory management
Process management
Handling for your system calls

History of Linux:

Before Linux:

UNIX: Developed in the 1970s at AT&T Bell Labs by Ken Thompson and Dennis Ritchie - UNIX is a proprietary operating system
GNU Project: In 1983, Richard Stallman launched the GNU(GNU’s Not UNIX) project - GNU is a free and open-source software
- While many tools and utilities were developed under the GNU project, a completely free OS was missing a kernel.

Birth of Linux:

1991: A 21-year-old Finland student named Linus Torvalds started developing a free OS kernel as a hobby project.
On August 25, 1991, Linus announced his project on the Minix newsgroup.

“I’m doing a (free) operating system (just a hobby, won’t be big and professional like GNU”)
Version 0.01 was released in September 1991
- Not Functional
- Released to the public
Version 0.02 Later in 1991
- Functional
- Combined with the utilities from the GNU project

It formed a completely free operating system.

Growth and Evolution:

The early 1990s: Linux rapidly evolved through collaboration over the Internet.
- So many distributions came like Slackware and Debian.
1993: Linux 1.0 was released with 176k lines of code.
Late 1990s: Commercial interest in Linux grew.
- Like Red Hat and SUSE
2000s: Linux saw significant adoption in server markets.
In 2007, Google released the Android OS for Mobile devices.

Today:

Linux has grown from a hobbyist’s project into a powerful force in computing, powering everything from mobile devices, personal computers, and servers to mainframes and supercomputers.

So simply put, the story of Linux isn’t about a computer system. It’s about great people from all over the world working together and making this reliable, secure, and open-source operating system.

Important things to remember in Linux:

Linux has a super-user account called root
- root is the most powerful account that can create, modify, delete accounts, and make changes to system configuration files. It even can delete the entire operating system.
Linux is a case-sensitive system
- ABC is NOT the same as abc
Avoid using spaces when creating files and directories
Linux kernel is not an OS. It is a small software within Linux OS that takes commands from users and passes them to system hardware or peripherals.
Linux is mostly CLI, not GUI
Linux is very flexible as compared to other operating systems.

Linux Filesystem:

It is a system used by an operating system to manage files. The system controls how data is saved or retrieved.

These are the Linux file system:

Ext4: This is the most widely used file system in Linux and it is known for its high performance, reliability, and scalability.
XFS: This is a high-performance file system that is optimized for large-scale data storage and is commonly used in enterprise and high-performance computing environments.
Btrfs: This is a newer file system that is designed to be flexible, scalable, and easy to manage.

These are the Windows files system:

NTFS: This is a file system commonly used in Microsoft Windows and it is supported by most modern Linux distributions.
FAT32: This is an older file system that is commonly used in older Microsoft Windows systems and is also widely used for removable storage devices such as USB drives and has limitations such as a maximum file size of 4GB.

File System Structure and its Description:

/ (Root Directory): The top-level directory that contains the entire file system hierarchy.
/boot: Holds files essential for the system's boot process, including the kernel and bootloader configuration.
/bin: Contains fundamental binary executables (commands) accessible to all users.
/etc: Stores system-wide configuration files and directories, including application-specific configurations.
/home: Home directories for individual users.
/lib and /lib64: Libraries required for the functioning of executables in /bin and /sbin.
/sbin: Contains system binaries used for system administration tasks, requiring superuser privileges.
/usr: Holds user-related programs, libraries, and documentation.
/var: Contains variable data such as log files, mail, and temporary files.
/tmp: A directory for temporary files accessible to all users; contents are typically cleared on system reboot.
/dev: Contains device files representing physical and virtual devices attached to the system.
/proc: A virtual file system providing information about processes and system resources.
/sys: A virtual file system exposing kernel parameters and settings.
/mnt: Traditionally used as a mount point for temporary filesystems or external devices.
/opt: Used for the installation of additional software packages not part of the default system installation.
/srv: Intended for data served by the system, such as website content or file-sharing services.
/root: Home directory for the root user (superuser).
/run: A temporary filesystem holding runtime information about the system since the last boot.
/lost+found: Used by the fsck utility to store recovered files and fragments during filesystem repair.
fsck

fsck is a command-line utility used for checking and repairing file system inconsistencies, and the /lost+found directory is used by fsck to store recovered files and fragments during the repair process.

What is Root?

There are 3 types of root in the Linux system:
1. Root account: root is an account or a username on a Linux machine and it is the most powerful account that has access to all commands and files.
2. Root as /: the very first directory in Linux is also referred to as a root directory.
3. Root home directory: the root user account also has a directory located in /root which is called root home directory and accessed by /home command.

Linux file types:

Above you can see the file type starts with:

d - is a directory
' - ' is a file

Below you can see more:

File System Paths:

There are two paths to navigate to a filesystem:
1. Absolute Path:
  - An absolute path always begins with a '/'. This indicates that the path starts at the root directory. An example of an absolute path is:
    
    cd /var/log/suraj

2. Relative Path:

    - A relative path does not begin with a “/”. It identifies a location relative to your current position. An example of a relative path is:

    `cd /var`

    `cd log`

    `cd suraj`

Find Files and Directories:

Two main commands are used to find files/directories
- find
- locate

These are the key differences between find and locate

locate, uses a prebuilt database, which should be regularly updated, while find iterates over a filesystem to locate files. Thus, locate is much faster than find, but can be inaccurate if the database (can be seen as a cache) is not updated.
to update locate database run updatedb

Here is how we can do it hands-on:

WildCards:

A wildcard is a character that can be used as a substitute for any of class of characters in a search
- represents zero or more characters
- ? - represents a single character
- [ ] represents a range of character
- do explore other wildcards

Here is how we can do it hands-on:

The end: I'm pretty sure with you'll fall in love with LInux. So do explore linux at your own and see you in the next part.

Forem: Suraj

Fix Wrong Authors Commits the Safe Way Using Git Rebase

Introduction

What You'll Learn

Why This Approach Works

Git Rebase : The Foundation

What is Git Rebase?

What is Git Merge?

When to Use?

Why Use Interactive Rebase for Fixes?

Rebase vs Merge: Quick Comparison

Interactive Rebase: What Happens Under the Hood

Visual: Before & After (Actual Git Output)

🐳 Setting Up Your Docker Git Lab: Let's do it hands-on

Build & Run the Lab with the Docker image and clone the GitHub repo:

Run interactive container

Lab Exercise: Creating the Problem

Step 0: Create a feature branch

Step 1: Set Wrong Global Identity

Step 2: Let's make some Commits

Step 3: Check the Damage

Step 4: Set Correct Repo-Level Identity

Scenario 1: Fix Local Commits (Before Push)

Interactive Rebase in Action

Mark Commits for Editing

Fix Each Commit

Verify the Fix

Scenario 1.1: Fix Initial Commit (Including Root)

The Problem: Initial Commit Has Wrong Author

The Solution: Use -root Flag

Mark Commits (Including Root) for Editing

Fix Each Commit (Same Process)

Why -root is Essential

Scenario 2: Wrong Author Already Pushed (Branch Not Merged)

Setup: Push to Remote Branch

Fix and Force Push

Scenario 3: Wrong Author Already Merged to Main

Option 1: Accept and Document (✅ Recommended)

Option 2: Rewrite Main (⚠️ Dangerous)

Advanced Tips & Best Practices

Prevent Future Mistakes

When NOT to Rewrite History

Quick Reference: Rebase Commands

Complete Setup Commands Summary

Your Next Steps

Happy rebasing!

Why NGINX Still Powers the Modern Web in 2025: Part 1

Introduction

What is Forward Proxy and Reverse Proxy?

Forward Proxy:

Reverse Proxy:

Understanding NGINX: Architecture & Use Cases

What is NGINX?

What problem it solves?

Why NGINX Became Essential:

NGINX Architecture: The Process Model

Why This Architecture Matters:

Core Use Cases

NGINX Alternatives

Setting Up Nginx with Docker: Hands-On

Prerequisites

Step 1: Setting Up the Docker Container

Step 2: Installing Nginx and Essential Tools

Step 3: Verify Nginx Installation

Step 4: Understanding Nginx Directory Structure

Step 5: Managing Nginx Service

Starting Nginx

Checking Nginx Status

Stopping Nginx

Step 6: Testing Your Nginx Installation

Step 7: Creating a Custom Configuration

Backup the Original Configuration

Create New Configuration File

Add Custom Configuration

Step 8: Testing and Reloading Configuration

Test Configuration Syntax

Reload Configuration

Verify Your Changes

Common Commands Summary

In the next parts of this nignx blogs we’ll learn:

The Solution: Use `-root` Flag

Why `-root` is Essential

What is `git cherry-pick`?

Now let’s understand a quick comparison `cherry-pick` vs `merge` vs `rebase`

Why You Might Need `cherry-pick`

My Real-Time Scenario: How I Discovered `cherry-pick`

Step-by-Step Practical Guide to `git cherry-pick`

1. View Commit History with `git log`

Step 3: Configure SSH `config` File