Technical Blog Comprehension

Title: Why Your Docker Images Are So Large (And How to Fix It)

A common pain point for developers new to Docker is discovering their image is 1.2 GB
when it only needs to be 80 MB. Here's why this happens and how to solve it.

The most common culprits:

1. Using a full OS base image
   FROM ubuntu:22.04 adds ~80 MB immediately. But many apps don't need a full OS.
   Fix: Use minimal base images like alpine (5 MB) or distroless images.
   FROM node:18-alpine instead of FROM node:18 cuts the image from ~900 MB to ~170 MB.

2. Not using multi-stage builds
   If you compile code (Go, Java, TypeScript), the build tools don't belong in the
   final image. A multi-stage build compiles in one stage and copies only the binary
   to a clean final image.

   # Build stage
   FROM golang:1.21 AS builder
   WORKDIR /app
   COPY . .
   RUN go build -o server .

   # Final stage — no Go toolchain
   FROM alpine:3.19
   COPY --from=builder /app/server .
   CMD ["./server"]

   Result: final image goes from ~800 MB (with Go toolchain) to ~12 MB.

3. Leaving package manager caches
   RUN apt-get install -y curl creates a cache that bloats the image.
   Fix: RUN apt-get install -y curl && apt-get clean && rm -rf /var/lib/apt/lists/*

4. Copying unnecessary files
   COPY . . copies everything, including node_modules, .git, and test files.
   Fix: Add a .dockerignore file (like .gitignore for Docker).

Key principle: Every RUN, COPY, and ADD instruction creates a new layer.
Unnecessary files added in one layer cannot be removed by a later layer.
They must be excluded from the start.

• A The build time is reduced from several minutes to under a minute
• B The final image size is reduced from approximately 800 MB to approximately 12 MB
• C The Go toolchain is moved to a separate optional layer
• D The image becomes compatible with Alpine and Ubuntu simultaneously

Title: Why Your Docker Images Are So Large (And How to Fix It)

A common pain point for developers new to Docker is discovering their image is 1.2 GB
when it only needs to be 80 MB. Here's why this happens and how to solve it.

The most common culprits:

1. Using a full OS base image
   FROM ubuntu:22.04 adds ~80 MB immediately. But many apps don't need a full OS.
   Fix: Use minimal base images like alpine (5 MB) or distroless images.
   FROM node:18-alpine instead of FROM node:18 cuts the image from ~900 MB to ~170 MB.

2. Not using multi-stage builds
   If you compile code (Go, Java, TypeScript), the build tools don't belong in the
   final image. A multi-stage build compiles in one stage and copies only the binary
   to a clean final image.

   # Build stage
   FROM golang:1.21 AS builder
   WORKDIR /app
   COPY . .
   RUN go build -o server .

   # Final stage — no Go toolchain
   FROM alpine:3.19
   COPY --from=builder /app/server .
   CMD ["./server"]

   Result: final image goes from ~800 MB (with Go toolchain) to ~12 MB.

3. Leaving package manager caches
   RUN apt-get install -y curl creates a cache that bloats the image.
   Fix: RUN apt-get install -y curl && apt-get clean && rm -rf /var/lib/apt/lists/*

4. Copying unnecessary files
   COPY . . copies everything, including node_modules, .git, and test files.
   Fix: Add a .dockerignore file (like .gitignore for Docker).

Key principle: Every RUN, COPY, and ADD instruction creates a new layer.
Unnecessary files added in one layer cannot be removed by a later layer.
They must be excluded from the start.

• A Delete them in a separate RUN instruction after copying
• B Use a multi-stage build to exclude them from the final stage
• C Add a .dockerignore file to prevent them from being copied at all
• D Compress them with zip before copying to reduce layer size

Understanding Git Rebase vs. Merge: When to Use Each

Both git merge and git rebase integrate changes from one branch into another,
but they do it differently and leave different histories.

git merge creates a merge commit
  When you merge feature into main, Git creates a new commit that has two parents:
  the tip of main and the tip of feature. This preserves the exact history of
  when branches diverged and reunited.

  Pros: Non-destructive, preserves exact timeline, safe for shared branches
  Cons: Adds merge commits that can clutter history ("merge noise")

git rebase rewrites history
  Rebase takes your feature branch commits and replays them on top of the target
  branch as if they were made there from the beginning. The result is a linear history
  with no merge commits.

  Pros: Clean, linear history that's easier to read with git log
  Cons: Rewrites commit SHAs — NEVER rebase commits that have been pushed to a
        shared branch (it will cause conflicts for everyone else)

The golden rule of rebase:
  Never rebase public history. Only rebase local, unpublished branches.
  Once a branch is pushed and others are working on it, use merge instead.

A common workflow:
  1. Rebase your feature branch onto the latest main before opening a PR
     (keeps your branch up to date, linear history)
  2. Use merge (or squash merge) when closing the PR into main
     (clear record of when the feature was integrated)

• A Whenever you want a clean linear history, regardless of whether the branch is shared
• B Only on the main branch after a feature is merged
• C Only on local, unpublished branches that others have not yet worked on
• D After a pull request has been opened but before it is merged