DEV Community: Sanudin

Meta Tag HTML — Catatan Pribadi

Sanudin — Wed, 12 Aug 2026 15:40:33 +0000

🌐 Baca artikel ini dalam Bahasa Inggris di sini

Saya selalu mencari-cari lagi hal ini setiap memulai proyek baru, jadi ini tempat untuk mengumpulkan semuanya jadi satu — lengkap dengan catatan singkat kenapa masing-masing penting, supaya di masa depan tidak perlu memikirkan ulang dari nol.

Lompat ke:

Pengaturan Dasar Dokumen dan Responsif
SEO dan Indexing Dasar
Social Card (OG + X)
GEO / AI Crawler
Header Keamanan
PWA / Browser
Tabel Referensi
Yang Saya Pakai

Pengaturan Dasar Dokumen dan Responsif

<meta charset="UTF-8">
<meta name="viewport" content="width=device-width, initial-scale=1.0">

charset="UTF-8" — harus berada di bagian atas <head>. Jika browser menemukan byte non-ASCII sebelum menemukan deklarasi charset, dokumen bisa saja di-parse ulang dari awal.
viewport — tanpa ini, tampilan mobile hanya menampilkan layout desktop yang di-zoom out. Wajib, selalu disertakan.

SEO dan Indexing Dasar

<meta name="description" content="...">
<meta name="robots" content="index, follow">
<link rel="canonical" href="https://sanudin.dev/">

description — cuplikan yang muncul di bawah link pada hasil pencarian, sekitar 150–160 karakter. Tidak langsung memengaruhi ranking, tapi memengaruhi click-through rate.
robots — defaultnya sudah index, follow, jadi tag ini hanya perlu dipasang jika saya ingin sebaliknya (noindex, nofollow pada rute staging).
canonical — menunjuk ke URL "asli" ketika konten yang sama bisa diakses lewat beberapa URL (trailing slash, query parameter, dan sejenisnya).

Social Card (OG + X)

Open Graph adalah standar universal untuk preview card di Facebook, LinkedIn, Discord, dan Slack. X menggunakan fallback ke OG kecuali saya menambahkan tag twitter:* secara khusus.

Ukuran gambar yang perlu diingat: 1200×630px (rasio 1.91:1).

<meta property="og:type" content="website">
<meta property="og:title" content="Sanudin | Software Engineer">
<meta property="og:description" content="Backend-first software engineer writing about web development, from Indonesia.">
<meta property="og:image" content="https://sanudin.dev/og-cover.png">
<meta property="og:url" content="https://sanudin.dev/">
<meta property="og:site_name" content="Sanudin">
<meta property="og:image:width" content="1200">
<meta property="og:image:height" content="630">

<meta name="twitter:card" content="summary_large_image">
<meta name="twitter:title" content="Sanudin | Software Engineer">
<meta name="twitter:description" content="Backend-first software engineer writing about web development, from Indonesia.">
<meta name="twitter:image" content="https://sanudin.dev/og-cover.png">

Pengingat: og:type sebaiknya article untuk halaman blog post, sementara website hanya untuk homepage atau landing page.

GEO / AI Crawler

Ada dua tempat terpisah untuk mengatur hal ini — meta tag (level halaman) dan robots.txt (level situs).

<meta name="robots" content="noai, noimageai">

User-agent: GPTBot
Disallow: /

User-agent: ClaudeBot
Disallow: /

User-agent: Googlebot
Allow: /

Catatan untuk diri sendiri: noai/noimageai bukan tag standar resmi (bermula dari DeviantArt, 2022) — adopsinya masih tidak merata. robots.txt adalah yang benar-benar berpengaruh jika saya peduli soal pemblokiran AI training.

JSON-LD untuk identitas — kenapa ini penting

Blok ini bukan untuk manusia, melainkan untuk search engine dan sistem AI yang mencoba mengenali siapa yang sedang berbicara. Halaman yang penuh teks "Saya Sanudin, software engineer" adalah sesuatu yang harus mereka simpulkan sendiri; blok JSON-LD langsung menyatakannya sebagai fakta terstruktur.

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "Person",
  "name": "Sanudin",
  "jobTitle": "Software Engineer",
  "url": "https://sanudin.dev",
  "sameAs": [
    "https://github.com/sanudin-dev",
    "https://linkedin.com/in/sanudin"
  ],
  "knowsAbout": ["TypeScript", "Next.js", "Node.js", "PHP", "Web Development"]
}
</script>

@type: "Person" — menandai ini secara spesifik sebagai data tentang sebuah entitas, bukan sekadar konten halaman. Ini yang membedakan search engine menebak-nebak siapa penulisnya dengan diberi tahu secara langsung.
sameAs — field inilah yang benar-benar bekerja. Field ini yang memungkinkan search engine atau sistem AI menghubungkan "Sanudin di GitHub," "Sanudin di LinkedIn," dan "Sanudin di sanudin.dev" sebagai orang yang sama, bukan tiga sebutan yang tidak berhubungan. Tanpa array ini, setiap profil menjadi pulau tersendiri.
jobTitle — perlu sama persis dengan wording bio kanonik saya ("Software Engineer," bukan sinonimnya). Konsistensi di semua profil itulah yang sebenarnya membangun asosiasi entitas ini — jika tidak cocok, justru berlawanan dengan tujuan blok ini.
knowsAbout — sinyal topik, bukan keyword stuffing. Harus benar-benar merefleksikan apa yang didukung oleh konten situs, kalau tidak hanya menjadi noise.
Sebelum publish: periksa lewat Google Rich Results Test atau schema.org validator. JSON-LD gagalnya diam-diam — kesalahan penulisan hanya akan diabaikan, bukan memunculkan error yang akan saya sadari.
Ini adalah schema identitas situs. Jika nanti ingin setiap post memiliki structured data sendiri, itu tipe Article terpisah dengan field author yang menunjuk kembali ke Person ini — tambahan untuk nanti, bukan sesuatu yang perlu dikerjakan sekarang.

Header Keamanan

Content Security Policy — fungsi masing-masing bagiannya

<meta http-equiv="Content-Security-Policy"
      content="default-src 'self'; script-src 'self' https://trustedscripts.com; style-src 'self' 'unsafe-inline'; img-src 'self' data: https:;">

default-src 'self' — baseline: tidak ada yang boleh dimuat kecuali dari origin yang sama. Setiap directive di bawah ini adalah pengecualian dari aturan ini.
script-src 'self' https://trustedscripts.com — hanya script milik saya sendiri dan satu domain yang di-whitelist ini yang boleh berjalan. Ini directive yang benar-benar penting untuk menghentikan script hasil injeksi/XSS — fakta bahwa saya tidak menambahkan 'unsafe-inline' di sini adalah bagian pentingnya, bukan kelalaian.
style-src 'self' 'unsafe-inline' — 'unsafe-inline' di sini adalah trade-off yang nyata, bukan default yang bisa diabaikan begitu saja. Diperlukan karena banyak framework menyuntikkan style="" saat runtime, tapi ini memang melemahkan proteksi terhadap inline style hasil injeksi (ada teknik CSS-based UI-redress/exfiltration nyata yang memanfaatkan celah ini). Risikonya jauh lebih kecil dibanding jika ini dipasang pada script-src, tapi jika suatu saat ingin menutup celah ini, solusinya adalah nonce atau hash per blok style, bukan sekadar menghapus directive-nya.
img-src 'self' data: https: — data: mengizinkan gambar base64 inline (ikon kecil, placeholder), https: mengizinkan gambar dari domain HTTPS mana pun secara luas sehingga tidak perlu mempertahankan daftar allowlist untuk setiap domain gambar.

Pengingat soal keterbatasan lewat meta tag: frame-ancestors, report-uri/report-to, dan sandbox tidak berfungsi jika CSP diatur lewat <meta> — hanya bisa lewat HTTP header sesungguhnya. Alasannya soal timing: proteksi-proteksi spesifik itu harus sudah aktif sebelum halaman mulai memuat apa pun, dan meta tag yang berada di dalam HTML sudah terlambat untuk itu. Versi meta ini adalah fallback untuk kondisi di mana saya tidak memiliki kendali atas header server (static hosting), bukan pengganti penuh.

Referrer Policy — apa yang sebenarnya dikirim oleh `strict-origin-when-cross-origin`

<meta name="referrer" content="strict-origin-when-cross-origin">

Rincian apa yang sebenarnya dilakukan value ini, karena "strict-origin-when-cross-origin" tidak menjelaskan dirinya sendiri:

Request same-origin → mengirim URL lengkap (path + query string).
Request cross-origin, tapi level keamanan protokol sama (https → https) → hanya mengirim origin-nya (scheme + host), bukan path-nya.
Request downgrade (https → http) → tidak mengirim apa pun.

Kenapa ini penting: tanpa ini, mengklik link keluar bisa membocorkan path internal dan query string situs ke situs tujuan link tersebut. Catatan untuk diri sendiri: sebagian besar browser modern sekarang sudah default ke kebijakan ini secara persis, jadi tag ini lebih soal eksplisit dan berjaga-jaga jika default-nya berubah (atau ada policy lain yang diatur di tempat lain yang berkonflik) daripada benar-benar wajib hari ini.

Value lain yang perlu diingat jika membutuhkan yang lebih ketat atau lebih longgar: no-referrer (tidak mengirim apa pun sama sekali — paling privat, tapi bisa mengganggu analytics atau alur auth berbasis referrer), same-origin (tidak ada yang cross-origin sama sekali), unsafe-url (selalu mengirim URL lengkap — sebaiknya dihindari, paling banyak bocor).

PWA / Browser

<meta name="theme-color" media="(prefers-color-scheme: light)" content="#ffffff">
<meta name="theme-color" media="(prefers-color-scheme: dark)" content="#09090b">

Mewarnai UI chrome browser itu sendiri (address bar mobile, kartu task-switcher OS) agar sesuai dengan halaman. Dua deklarasi karena prefers-color-scheme adalah media query — satu tag tanpa itu akan memakai warna yang sama terlepas dari tema sistem.

<meta name="mobile-web-app-capable" content="yes">
<meta name="apple-mobile-web-app-status-bar-style" content="black-translucent">
<meta name="apple-mobile-web-app-title" content="Sanudin">

mobile-web-app-capable — membuat halaman masuk ke standalone mode (tanpa URL bar, tanpa navigasi browser) saat dibuka dari home screen. Ini tag yang sekarang berlaku, tanpa prefix — Chrome DevTools sekarang secara aktif menandai apple-mobile-web-app-capable yang lama sebagai deprecated dan meminta beralih ke versi ini. Safari secara historis hanya mengenali versi apple-prefixed, jadi mungkin masih perlu keduanya untuk iOS lama — perlu dicek ulang dukungan Safari terkini sebelum benar-benar meninggalkan tag lama. Selain itu: mulai iOS 26, Safari sekarang secara default membuat semua situs yang ditambahkan ke home screen langsung terbuka dalam mode web-app, sehingga tag ini pengaruhnya lebih kecil di iOS dibanding sebelumnya.
apple-mobile-web-app-status-bar-style — masih Apple-only, belum ada pengganti standar. black-translucent membuat konten halaman bisa scroll edge-to-edge di bawah status bar; default/black mempertahankan bar yang solid.
apple-mobile-web-app-title — juga masih Apple-specific, mengatur label di bawah ikon home screen. Pendekatan modernnya adalah mengatur ini lewat name/short_name di manifest.json — tag meta ini dipertahankan sebagai fallback karena Safari tidak selalu membaca nama dari manifest secara konsisten.

Catatan yang lebih besar untuk diri sendiri: panduan resmi saat ini (Chrome/web.dev) adalah lebih mengandalkan Web App Manifest untuk semua ini dalam jangka panjang, bukan meta tag-meta tag ini — mereka sudah ada sebelum spesifikasi manifest dan bisa menghasilkan fallback behavior yang lebih buruk jika manifest gagal dimuat. Anggap semua di atas sebagai lapisan kompatibilitas praktis, bukan kondisi ideal.

<link rel="manifest" href="/manifest.json">
<link rel="apple-touch-icon" href="/icons/apple-icon-180.png">
<link rel="icon" href="/favicon.ico" sizes="any">
<link rel="icon" href="/icon.svg" type="image/svg+xml">

Ini fondasi sebenarnya — manifest.json adalah tempat name, icons, start_url, display mode, dan theme color seharusnya berada ke depannya. apple-touch-icon tetap dipisah sebagai link karena Safari memperlakukannya sebagai override, bukan membaca icon dari manifest secara konsisten.

Tabel Referensi

Tag	Fungsi
`charset`	Encoding karakter yang benar
`viewport`	Rendering responsif di mobile
`description`	Teks cuplikan SERP
`robots`	Instruksi index/crawl
`canonical`	Menghindari masalah duplicate-content
`og:*`	Preview card (FB, LinkedIn, Discord)
`twitter:*`	Preview card di X
`robots: noai, noimageai`	Sinyal opt-out AI training (sukarela)
`robots.txt` (GPTBot, dll)	Blokir AI crawler level situs
JSON-LD (`Person`)	Data identitas terstruktur untuk AI/search
`Content-Security-Policy`	Membatasi sumber script/style/media yang diizinkan
`referrer`	Mengontrol data referrer yang keluar
`theme-color`	Warna chrome browser mobile
`mobile-web-app-capable`	Mode standalone (tag yang berlaku sekarang)
`apple-mobile-web-app-*`	Perilaku home screen khusus iOS
`manifest`	Kemampuan install PWA

Yang Saya Pakai

Selalu: charset, viewport, description, canonical, og:/twitter:.

Setelah dasarnya beres: robots (hanya jika benar-benar butuh noindex), theme-color, tag PWA, CSP.

Situasional, dicek ulang jika relevan: tag GEO, JSON-LD.

Originally published at: HTML Meta Tags: My Reference Notes

HTML Meta Tags: My Reference Notes

Sanudin — Wed, 12 Aug 2026 15:30:50 +0000

🌐 Read this post in Bahasa Indonesia here

I keep re-looking these up every time I start a new project, so this is where I'm dumping them all in one place — with a short note on why each one matters, so future-me doesn't have to re-derive it from scratch.

Jump to:

Document Core and Responsive Setup
Basic SEO and Indexing
Social Cards (OG + X)
GEO / AI Crawlers
Security Headers
PWA / Browser
Quick Table
What I Actually Use

Document Core and Responsive Setup

<meta charset="UTF-8">
<meta name="viewport" content="width=device-width, initial-scale=1.0">

charset="UTF-8" — needs to sit near the top of <head>, or the browser can end up re-parsing the whole doc if it hits non-ASCII bytes first.
viewport — without it, mobile just renders the desktop layout zoomed way out. Non-negotiable, always include.

Basic SEO and Indexing

<meta name="description" content="...">
<meta name="robots" content="index, follow">
<link rel="canonical" href="https://sanudin.dev/">

description — the snippet under my link in search results, ~150–160 chars. Doesn't move ranking directly, but affects click-through.
robots — default is already index, follow, so I only need this tag when I want the opposite (noindex, nofollow on staging routes).
canonical — points to the "real" URL when the same content is reachable multiple ways (trailing slash, query params, etc).

Social Cards (OG + X)

Open Graph = the universal standard for FB/LinkedIn/Discord/Slack preview cards. X falls back to OG unless I add twitter:* tags specifically.

Image size to remember: 1200×630px (1.91:1 ratio).

<meta property="og:type" content="website">
<meta property="og:title" content="Sanudin | Software Engineer">
<meta property="og:description" content="Backend-first software engineer writing about web development, from Indonesia.">
<meta property="og:image" content="https://sanudin.dev/og-cover.png">
<meta property="og:url" content="https://sanudin.dev/">
<meta property="og:site_name" content="Sanudin">
<meta property="og:image:width" content="1200">
<meta property="og:image:height" content="630">

<meta name="twitter:card" content="summary_large_image">
<meta name="twitter:title" content="Sanudin | Software Engineer">
<meta name="twitter:description" content="Backend-first software engineer writing about web development, from Indonesia.">
<meta name="twitter:image" content="https://sanudin.dev/og-cover.png">

Reminder: og:type should be article on blog posts, website is only for the homepage/landing pages.

GEO / AI Crawlers

Two separate places to control this — meta tag (page-level) and robots.txt (site-wide).

<meta name="robots" content="noai, noimageai">

User-agent: GPTBot
Disallow: /

User-agent: ClaudeBot
Disallow: /

User-agent: Googlebot
Allow: /

Note to self: noai/noimageai isn't an official spec tag (started at DeviantArt, 2022) — adoption is spotty at best. robots.txt is the one that actually does something if I care about blocking AI training.

JSON-LD for identity — why I bother with this

This block isn't for humans, it's for search engines and AI systems trying to figure out who is talking. A page full of prose saying "I'm Sanudin, a software engineer" is something they have to infer; a JSON-LD block just states it as structured fact.

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "Person",
  "name": "Sanudin",
  "jobTitle": "Software Engineer",
  "url": "https://sanudin.dev",
  "sameAs": [
    "https://github.com/sanudin-dev",
    "https://linkedin.com/in/sanudin"
  ],
  "knowsAbout": ["TypeScript", "Next.js", "Node.js", "PHP", "Web Development"]
}
</script>

@type: "Person" — marks this specifically as data about an entity, not just page content. This is the difference between search engines guessing at who wrote something vs. being told directly.
sameAs — this is the field doing the real work. It's what lets a search engine or AI system connect "Sanudin on GitHub," "Sanudin on LinkedIn," and "Sanudin on sanudin.dev" as the same person instead of three unrelated mentions. Without this array, every profile is an island.
jobTitle — needs to match my canonical bio wording exactly ("Software Engineer," not a synonym). Consistency across every profile is literally what builds the entity association — a mismatch works against the whole point of this block.
knowsAbout — a topical signal, not keyword stuffing. Should genuinely reflect what the site's content backs up, or it's just noise.
Before publishing: run it through Google's Rich Results Test or the schema.org validator. JSON-LD fails silently — a typo just gets ignored rather than throwing an error I'd notice.
This is site identity schema. If I want individual posts to carry their own structured data later, that's a separate Article type with an author field pointing back to this Person — a future addition, not something I need to retrofit now.

Security Headers

Content Security Policy — what each part is actually doing

<meta http-equiv="Content-Security-Policy"
      content="default-src 'self'; script-src 'self' https://trustedscripts.com; style-src 'self' 'unsafe-inline'; img-src 'self' data: https:;">

default-src 'self' — the baseline: nothing loads unless it's same-origin. Every other directive below is an exception to this.
script-src 'self' https://trustedscripts.com — only my own scripts and this one whitelisted domain can execute. This is the directive that actually matters for stopping injected/XSS scripts — the fact that I haven't added 'unsafe-inline' here is the important part, not an oversight.
style-src 'self' 'unsafe-inline' — 'unsafe-inline' here is a real trade-off, not a default I should ignore. It's needed because a lot of frameworks inject style="" at runtime, but it does weaken protection against injected inline styles specifically (there are real CSS-based UI-redress/exfiltration tricks that rely on exactly this). Much smaller risk than allowing it on script-src, but if I ever want to close this gap, the fix is nonces or hashes per style block, not just removing the directive.
img-src 'self' data: https: — data: allows base64-inlined images (small icons, placeholders), https: broadly allows images from any HTTPS source so I'm not maintaining an allowlist of every image domain.

Reminder on the meta-tag limitation: frame-ancestors, report-uri/report-to, and sandbox don't work when CSP is set via <meta> — only via an actual HTTP header. The reason is timing: those specific protections need to be enforced before the page starts loading anything, and a meta tag sitting inside the HTML is already too late for that. This meta version is a fallback for when I don't control server headers (static hosting), not a full substitute.

Referrer Policy — what `strict-origin-when-cross-origin` actually sends

<meta name="referrer" content="strict-origin-when-cross-origin">

Breaking down what this value actually does, since "strict-origin-when-cross-origin" doesn't explain itself:

Same-origin request → sends the full URL (path + query string).
Cross-origin request, but same protocol security level (https → https) → sends only the origin (scheme + host), not the path.
Downgrade request (https → http) → sends nothing at all.

Why this matters: without it, clicking an outbound link can leak my site's internal paths and query strings to whatever site the link points to. Note to self: most modern browsers already default to this exact policy now, so this tag is more about being explicit and guarding against a future default change (or another policy set elsewhere conflicting) than strictly necessary today.

Other values worth remembering if I need something stricter or looser: no-referrer (send nothing, ever — most private, but can break analytics or referrer-based auth flows), same-origin (nothing at all cross-origin), unsafe-url (always send the full URL — avoid, leaks the most).

PWA / Browser

<meta name="theme-color" media="(prefers-color-scheme: light)" content="#ffffff">
<meta name="theme-color" media="(prefers-color-scheme: dark)" content="#09090b">

Colors the browser's own UI chrome (mobile address bar, OS task-switcher card) to match the page. Two declarations because prefers-color-scheme is a media query — a single tag without it would apply the same color regardless of system theme.

<meta name="mobile-web-app-capable" content="yes">
<meta name="apple-mobile-web-app-status-bar-style" content="black-translucent">
<meta name="apple-mobile-web-app-title" content="Sanudin">

mobile-web-app-capable — puts the page into standalone mode (no URL bar, no browser nav) when launched from the home screen. This is the current, unprefixed tag — Chrome DevTools actively flags the old apple-mobile-web-app-capable as deprecated now and asks for this version instead. Safari historically only recognized the apple-prefixed one, so I may still need both for older iOS — worth rechecking current Safari support before dropping the legacy tag entirely. Also: as of iOS 26, Safari defaults every home-screen-added site to open in web-app mode regardless, so this tag matters less on iOS than it used to.
apple-mobile-web-app-status-bar-style — still Apple-only, no standardized replacement exists yet. black-translucent lets page content scroll edge-to-edge under the status bar; default/black keep a solid bar instead.
apple-mobile-web-app-title — also still Apple-specific, controls the label under the home screen icon. The modern approach is to set this via name/short_name in manifest.json instead — keeping this meta tag around as a fallback since Safari doesn't always read the manifest name reliably.

Bigger note to self: the actual current guidance (Chrome/web.dev) is to lean on the Web App Manifest for all of this long-term, not these meta tags — they predate the manifest spec and can produce worse fallback behavior if the manifest fails to load. Treat everything above as a practical compatibility layer, not the ideal end state.

<link rel="manifest" href="/manifest.json">
<link rel="apple-touch-icon" href="/icons/apple-icon-180.png">
<link rel="icon" href="/favicon.ico" sizes="any">
<link rel="icon" href="/icon.svg" type="image/svg+xml">

This is the actual foundation — manifest.json is where name, icons, start_url, display mode, and theme colors are meant to live going forward. apple-touch-icon stays as a separate link because Safari treats it as an override rather than reliably reading icons from the manifest.

Quick Table

Tag	Purpose
`charset`	Correct character encoding
`viewport`	Responsive mobile rendering
`description`	SERP snippet text
`robots`	Index/crawl instructions
`canonical`	Avoid duplicate-content issues
`og:*`	Preview cards (FB, LinkedIn, Discord)
`twitter:*`	Preview cards on X
`robots: noai, noimageai`	Voluntary AI-training opt-out signal
`robots.txt` (GPTBot, etc.)	Site-wide AI crawler blocking
JSON-LD (`Person`)	Structured identity data for AI/search
`Content-Security-Policy`	Restrict allowed script/style/media sources
`referrer`	Control outbound referrer data
`theme-color`	Mobile browser chrome color
`mobile-web-app-capable`	Standalone launch mode (current tag)
`apple-mobile-web-app-*`	iOS-specific home screen behavior
`manifest`	PWA installability

What I Actually Use

Always: charset, viewport, description, canonical, og:/twitter:.

Once the basics are set: robots (only when I actually need noindex), theme-color, PWA tags, CSP.

Situational, revisit if it matters that day: GEO tags, JSON-LD.

Originally published at: HTML Meta Tags: My Reference Notes

Git & Collaboration: A Beginner's Guide (With Real Analogies)

Sanudin — Mon, 08 Jun 2026 00:39:41 +0000

🌐 Read this post in Bahasa Indonesia here.

📝 A note on this article
This post is based on my personal study notes. The ideas, learning journey, and understanding are mine — I used AI to help structure and expand them into a proper blog format form.

Learning Git doesn't have to be intimidating. In this article, I'll break down the essential concepts of version control and collaboration — using simple analogies that anyone can understand.

What Is Git?

Git is a version control system. Think of it as a save system for your code — like save points in a video game. Every time you save (commit), Git remembers the state of your project at that moment. If something goes wrong, you can always go back.

Repository: Your Project's Warehouse

A repository (or "repo") is the folder that Git watches. There are two types:

Local repository: lives on your computer. Your personal workspace.
Remote repository: lives on a server (GitHub, GitLab, Bitbucket). The "official" shared copy your team can access.

They stay connected through a Remote URL, so you can push your local changes up and pull others' changes down.

git init                            # Start tracking a folder
git remote add origin <url>         # Connect to a remote repo
git push origin main                # Send commits to remote
git pull origin main                # Get latest from remote

Commit: Your Project's Save Point

A commit is a snapshot of your project at a specific moment. Each commit has:

A message describing what changed
A unique ID (hash)
A timestamp

git add .                           # Stage all changes
git commit -m "Add homepage layout" # Save a snapshot
git log --oneline                   # View commit history

Write meaningful commit messages. Future you will thank present you.

Checkout, Reset, Revert: Traveling Through Time

These three commands all interact with your commit history — but in very different ways:

`git checkout` — Visit the Past (Temporarily)

Like a time traveler with a visitor's pass. You can look around at an old commit without changing anything permanently.

git checkout <commit-hash>          # Visit an old commit
git checkout main                   # Go back to the present
git checkout -b new-branch <hash>   # Start a new branch from old commit

`git reset` — Erase History

Goes back to a past commit and removes everything that came after. Use with care — especially if you've already pushed.

git reset --soft HEAD~1             # Undo last commit, keep changes staged
git reset --hard HEAD~1             # Undo last commit, delete changes too

`git revert` — The Safe Undo

Creates a new commit that reverses a previous one. History stays intact — the safest option when working on a shared repo.

git revert <commit-hash>            # Undo a commit safely

Rule of thumb: if you've already pushed, use revert. If you haven't, reset is fine.

Branches: Parallel Universes for Your Code

A branch is an independent line of development. You can create branches to work on features or fixes without touching the stable main branch.

git switch -c feature/dark-mode     # Create and switch to new branch
git switch main                     # Switch back to main
git branch -d feature/dark-mode     # Delete merged branch
git push origin feature/dark-mode   # Push branch to remote

A common branch naming convention:

Type	Prefix	Example
New feature	`feature/`	`feature/dark-mode`
Bug fix	`fix/`	`fix/login-redirect`
Urgent fix	`hotfix/`	`hotfix/payment-crash`

Stash: The Pause Button for Unfinished Work

You're halfway through a feature. Code is messy, not ready to commit. Then your team lead says: "Can you quickly fix that bug on main?"

You can't switch branches with uncommitted changes. But you're not ready to commit either. The answer: stash it.

Analogy: You're drawing a picture but need to use the table for something else. You put everything in a drawer. Later, you open the drawer and continue exactly where you left off.

git stash                           # Save work temporarily
git switch fix/some-bug             # Switch branches freely
# ... fix the bug, commit, come back ...
git switch feature/dark-mode
git stash pop                       # Restore your work

Adding a label makes it easier to manage multiple stashes:

git stash push -m "WIP: dark mode palette"   # Named stash
git stash list                               # See all stashes
git stash pop                                # Restore latest
git stash apply stash@{1}                    # Restore specific (keep in list)
git stash drop stash@{1}                     # Remove specific
git stash -u                                 # Include untracked (new) files

Worktree: No Stash Needed

Stash works well for quick interruptions. But if the other task is longer — or you simply don't want to touch your current work at all — Git Worktree is the cleaner solution.

Worktree lets you check out a second branch in a separate folder, without touching your current work:

# Create a new folder with a different branch checked out
git worktree add -b hotfix/login-bug ../my-project-hotfix origin/main

# Work in that folder, commit, push
cd ../my-project-hotfix
git add . && git commit -m "Fix login redirect"
git push origin hotfix/login-bug

# Remove the worktree when done
git worktree remove ../my-project-hotfix

Both folders share the same .git directory — one repo, two windows into it. GUI tools like GitHub Desktop, GitKraken, and Fork all recognize it as one repo.

	Stash	Worktree
Current work	Saved and hidden	Completely untouched
Multiple branches at once	❌	✅
Ideal for	Quick interruptions	Longer parallel work

Merge & Pull Requests: Bringing It All Together

When your feature is ready, you merge it back into main.

git switch main
git merge feature/dark-mode

On GitHub/GitLab, this is typically done through a Pull Request (PR) — a formal process where:

You push your branch and open a PR
Teammates review your code and leave feedback
Once approved, it gets merged

Merge Options

Method	What happens
Merge commit	All commits preserved + merge commit added
Squash and merge	All commits squashed into one
Rebase and merge	Commits replayed on top of main, no merge commit

Handling Conflicts

When two branches edit the same line, Git can't auto-merge. You'll see:

<<<<<<< HEAD
const msg = "Hello!";
=======
const msg = "Hi there!";
>>>>>>> feature/dark-mode

Manually resolve it, then:

git add <file>
git commit

Rebase: A Cleaner Alternative to Merge

When you're the only one working on a branch, rebase is a great way to keep your branch up to date with main — without creating merge commits.

Instead of merging main into your branch (which adds noise), rebase replays your commits on top of the latest main:

git fetch origin
git rebase origin/main

# If conflicts arise during rebase:
git add <file>
git rebase --continue   # move to next commit
git rebase --abort      # cancel and go back

# Force push after rebase (required — history was rewritten)
git push origin feature/dark-mode --force-with-lease

⚠️ Never rebase a branch other people are also working on. Rebase rewrites history — it's only safe when you're the sole author of that branch.

Situation	Use
Solo feature branch, want clean history	`rebase`
Shared branch or already merged	`merge`
Preparing a clean PR	`rebase` first, then open PR

Code Reviews: The Quality Gate

Before a PR is merged, someone reviews it. Good reviewers check for:

Logical correctness
Readability and naming
Test coverage
Complexity (is it simpler than it needs to be?)
Style guideline compliance

Code reviews aren't just about catching mistakes — they're also how knowledge spreads through a team.

Fork & Clone: Contributing Without Access

Forking copies someone else's repo into your GitHub account. Cloning copies a repo to your local machine.

The typical open-source contribution flow:

# 1. Fork on GitHub (click the Fork button)

# 2. Clone your fork
git clone https://github.com/your-username/the-project.git

# 3. Add original repo as upstream
git remote add upstream https://github.com/original-owner/the-project.git

# 4. Create a branch, make changes, push
git switch -c fix/typo-readme
git add . && git commit -m "Fix typo in README"
git push origin fix/typo-readme

# 5. Open a Pull Request on GitHub

Keeping Your Fork Synced

git fetch upstream
git switch main
git merge upstream/main
git push origin main

Git GUI Apps: You Don't Have to Type Everything

Knowing the commands makes you a stronger developer — but you don't have to use the terminal every day. There's a whole ecosystem of GUI (Graphical User Interface) apps that let you commit, branch, merge, and stash by clicking buttons, with a visual map of your repo history.

Here are the most popular ones:

App	Platform	Price	Best For
GitHub Desktop	Mac, Windows	Free	Beginners, GitHub users
GitLens (VS Code ext.)	All OS	Free / Paid	Devs living in VS Code/Cursor
GitKraken	Mac, Win, Linux	Free (limited) / Paid	Visual power users
Fork	Mac, Windows	Free trial / ~$50	Speed + power balance
Sourcetree	Mac, Windows	Free	Atlassian/Bitbucket users

GitHub Desktop is the simplest — made by GitHub, focused on the essentials.
GitLens is a VS Code extension that adds inline blame, visual commit graphs, and stash management right inside your editor.
GitKraken has a stunning commit graph and drag-and-drop merging.
Fork hits a great balance of speed and power.
Sourcetree (by Atlassian) is free and feature-rich, especially if you use Bitbucket.

Even if you use a GUI app daily, knowing the underlying commands helps you debug problems and work on servers where no GUI exists. Think of GUI apps as a productivity layer on top of your Git knowledge — not a replacement for it.

Summary

Concept	In Short
Repository	Warehouse for your project files + history
Commit	A saved snapshot with a message
Checkout	Visit past commits temporarily
Reset	Erase commit history (use carefully)
Revert	Safely undo a commit
Branch	Independent line of development
Stash	Temporarily save unfinished work
Worktree	Work on two branches at once in separate folders
Merge	Combine branches
Rebase	Replay your commits on top of another branch (solo branches only)
Pull Request	Formal request to review and merge code
Fork	Copy someone else's repo to your account
Clone	Copy a repo to your local machine

Git takes practice, but these concepts cover 90% of what you'll use day-to-day. Start small, commit often, and don't be afraid of making branches.

The more you use it, the more natural it feels.

One commit at a time. 🚀

Originally published as a series (Git for Everyone) at: What Is Git, Repository, and Commit | Traveling Through Time — Checkout, Reset, and Revert
| Branches, Stash, and Git Workflow | Merge, Pull Requests, and Code Reviews | Fork, Clone, and Open Source Collaboration | Git GUI Apps — You Don't Have to Use the Terminal

Git & Kolaborasi: Panduan untuk Pemula (Lengkap dengan Analogi)

Sanudin — Mon, 08 Jun 2026 00:36:09 +0000

🌐 Baca artikel ini dalam Bahasa Inggris di sini.

📝 Catatan tentang artikel ini
Artikel ini dibuat berdasarkan catatan belajar pribadi saya. Ide, perjalanan belajar, dan pemahamannya adalah milik saya — saya menggunakan AI untuk menyusun dan mengembangkannya menjadi artikel blog yang lebih muda dibaca.

Belajar Git itu tidak harus membingungkan. Di artikel ini, saya akan menjelaskan konsep-konsep penting dalam version control dan kolaborasi menggunakan bahasa yang sederhana — bahkan dengan analogi yang bisa dipahami anak kecil sekalipun.

Apa Itu Git?

Git adalah version control system — sistem yang merekam setiap perubahan yang kamu lakukan pada file-file proyekmu.

Bayangkan Git seperti fitur save point di video game. Setiap kali kamu menyimpan (commit), Git mengambil "foto" dari kondisi proyekmu saat itu. Kalau ada yang salah, kamu bisa kembali ke foto sebelumnya.

Repository: Gudang Proyekmu

Repository (atau "repo") adalah folder yang diawasi oleh Git. Ada dua jenisnya:

Local repository: ada di komputermu sendiri. Ruang kerja pribadimu.
Remote repository: ada di server (GitHub, GitLab, Bitbucket). Salinan "resmi" yang bisa diakses seluruh tim.

Keduanya terhubung lewat Remote URL, sehingga kamu bisa mengirim perubahan ke remote (push) atau mengambil perubahan terbaru dari sana (pull).

git init                            # Mulai memantau sebuah folder
git remote add origin <url>         # Hubungkan ke remote repo
git push origin main                # Kirim commit ke remote
git pull origin main                # Ambil update terbaru dari remote

Analogi: Local repo adalah buku sketsamu di rumah. Remote repo adalah papan pengumuman kelas — semua orang bisa melihat dan mengaksesnya.

Commit: Save Point Proyekmu

Commit adalah snapshot dari kondisi proyekmu pada satu titik waktu. Setiap commit berisi:

Pesan yang menjelaskan apa yang berubah
ID unik (hash)
Timestamp

git add .                           # Staging semua perubahan
git commit -m "Tambah layout halaman utama"  # Simpan snapshot
git log --oneline                   # Lihat riwayat commit

Tulis pesan commit yang jelas dan bermakna. Dirimu di masa depan — dan rekan timmu — akan berterima kasih.

Checkout, Reset, Revert: Mesin Waktu Git

Ketiga perintah ini berinteraksi dengan riwayat commit — tapi dengan cara yang sangat berbeda:

`git checkout` — Kunjungi Masa Lalu (Sementara)

Seperti mesin waktu dengan tiket visitor. Kamu bisa melihat kondisi kode di commit lama tanpa mengubah apapun secara permanen.

git checkout <commit-hash>          # Kunjungi commit lama
git checkout main                   # Kembali ke sekarang
git checkout -b branch-baru <hash>  # Buat branch baru dari commit lama

`git reset` — Hapus Riwayat

Kembali ke commit tertentu dan menghapus semua yang terjadi setelahnya. Gunakan dengan hati-hati — terutama jika sudah di-push ke remote.

git reset --soft HEAD~1             # Undo commit terakhir, perubahan tetap ada (staged)
git reset --hard HEAD~1             # Undo commit terakhir, perubahan ikut terhapus

`git revert` — Undo yang Aman

Membuat commit baru yang membalikkan efek dari commit sebelumnya. Riwayat tetap utuh — pilihan paling aman saat bekerja di repo bersama.

git revert <commit-hash>            # Undo sebuah commit dengan aman

Panduan praktis: Kalau sudah di-push, gunakan revert. Kalau belum, reset tidak masalah.

Branch: Jalur Paralel untuk Kode

Branch adalah jalur pengembangan yang terpisah. Kamu bisa membuat branch untuk mengerjakan fitur atau perbaikan bug tanpa menyentuh branch main yang stabil.

git switch -c feature/dark-mode     # Buat dan pindah ke branch baru
git switch main                     # Kembali ke main
git branch -d feature/dark-mode     # Hapus branch yang sudah di-merge
git push origin feature/dark-mode   # Push branch ke remote

Konvensi penamaan branch yang umum:

Tipe	Prefix	Contoh
Fitur baru	`feature/`	`feature/dark-mode`
Perbaikan bug	`fix/`	`fix/login-redirect`
Hotfix mendesak	`hotfix/`	`hotfix/payment-crash`

Analogi: Bayangkan sungai yang mengalir. Branch adalah anak sungai yang memisah diri untuk menjelajahi jalur lain — dan nantinya bergabung kembali ke sungai utama.

Stash: Tombol Pause untuk Pekerjaan yang Belum Selesai

Kamu sedang di tengah-tengah mengerjakan sebuah fitur. Kode masih berantakan, belum siap untuk di-commit. Tiba-tiba team lead bilang: "Bisa tolong perbaiki bug itu di branch main sekarang?"

Kamu tidak bisa switch branch dengan perubahan yang belum di-commit. Tapi kamu juga belum siap commit. Jawabannya: simpan dulu dengan stash.

Analogi: Kamu sedang menggambar tapi meja harus dipakai untuk hal lain. Kamu dengan rapi menyimpan gambar dan pensil ke dalam laci. Nanti kamu buka lacinya dan lanjut persis dari titik yang sama.

git stash                           # Simpan pekerjaan sementara
git switch fix/some-bug             # Bebas pindah branch
# ... perbaiki bug, commit, balik lagi ...
git switch feature/dark-mode
git stash pop                       # Kembalikan pekerjaanmu

Menambahkan label membuat stash lebih mudah dikelola:

git stash push -m "WIP: palet dark mode"     # Stash dengan nama
git stash list                               # Lihat semua stash
git stash pop                                # Kembalikan stash terbaru
git stash apply stash@{1}                    # Kembalikan stash tertentu (tetap di list)
git stash drop stash@{1}                     # Hapus stash tertentu
git stash -u                                 # Sertakan file baru yang belum di-track

Worktree: Tanpa Perlu Stash

Stash cocok untuk interupsi singkat. Tapi kalau tugasnya lebih panjang — atau kamu tidak ingin menyentuh pekerjaan saat ini sama sekali — Git Worktree adalah solusi yang lebih bersih.

Worktree memungkinkan kamu checkout branch kedua di folder terpisah, tanpa menyentuh pekerjaan yang sedang berjalan:

# Buat folder baru dengan branch yang berbeda
git worktree add -b hotfix/login-bug ../my-project-hotfix origin/main

# Kerjakan di folder itu, commit, push
cd ../my-project-hotfix
git add . && git commit -m "Fix login redirect"
git push origin hotfix/login-bug

# Hapus worktree setelah selesai
git worktree remove ../my-project-hotfix

Kedua folder berbagi satu .git directory yang sama — satu repo, dua jendela ke dalamnya. Tools seperti GitHub Desktop, GitKraken, dan Fork tetap mengenalinya sebagai satu repo.

	Stash	Worktree
Pekerjaan saat ini	Disimpan sementara	Sama sekali tidak tersentuh
Beberapa branch sekaligus	❌	✅
Cocok untuk	Interupsi singkat	Pekerjaan paralel yang lebih lama

Merge & Pull Request: Menyatukan Pekerjaan

Saat fiturmu selesai, kamu merge branch-mu kembali ke main.

git switch main
git merge feature/dark-mode

Di GitHub/GitLab, proses ini biasanya dilakukan lewat Pull Request (PR):

Push branch-mu dan buka PR
Rekan tim me-review kode dan meninggalkan komentar
Setelah disetujui, kode di-merge

Tiga Opsi Merge

Metode	Yang Terjadi
Merge commit	Semua commit dipertahankan + merge commit ditambahkan
Squash and merge	Semua commit digabung jadi satu
Rebase and merge	Commit diputar ulang di atas main, tanpa merge commit

Menangani Conflict

Ketika dua branch mengedit baris yang sama, Git tidak bisa merge otomatis. Kamu akan melihat:

<<<<<<< HEAD
const msg = "Halo!";
=======
const msg = "Hai semuanya!";
>>>>>>> feature/dark-mode

Selesaikan secara manual, lalu:

git add <file>
git commit

Rebase: Alternatif yang Lebih Bersih dari Merge

Ketika kamu satu-satunya yang mengerjakan sebuah branch, rebase adalah cara yang bagus untuk menjaga branch-mu tetap update dengan main — tanpa membuat merge commit yang mengotori riwayat.

Alih-alih merge main ke branch-mu, rebase memutar ulang commit-commitmu di atas main yang terbaru:

git fetch origin
git rebase origin/main

# Jika ada conflict saat rebase:
git add <file>
git rebase --continue   # lanjut ke commit berikutnya
git rebase --abort      # batalkan dan kembali ke sebelumnya

# Force push setelah rebase (wajib — karena riwayat sudah ditulis ulang)
git push origin feature/dark-mode --force-with-lease

⚠️ Jangan pernah rebase branch yang juga dikerjakan orang lain. Rebase menulis ulang riwayat — hanya aman jika kamu satu-satunya yang mengerjakan branch tersebut.

Situasi	Gunakan
Feature branch solo, ingin riwayat bersih	`rebase`
Branch bersama atau sudah di-merge	`merge`
Mempersiapkan PR yang bersih	`rebase` dulu, baru buka PR

Code Review: Pintu Gerbang Kualitas

Sebelum PR di-merge, seseorang akan me-review kodenya. Reviewer yang baik memeriksa:

Apakah logikanya benar?
Apakah kode mudah dibaca dan penamaannya jelas?
Apakah ada test yang cukup?
Apakah kode lebih kompleks dari yang seharusnya?
Apakah sesuai dengan style guideline tim?

Code review bukan sekadar mencari kesalahan — ini juga cara pengetahuan menyebar di seluruh tim. Jangan lupa juga memberikan pujian ketika kode sudah ditulis dengan baik.

Fork & Clone: Berkontribusi Tanpa Akses

Forking menyalin repo orang lain ke akun GitHub-mu. Cloning menyalin repo ke komputer lokalmu.

Alur kontribusi open source yang umum:

# 1. Fork di GitHub (klik tombol Fork)

# 2. Clone fork-mu
git clone https://github.com/username-kamu/nama-proyek.git

# 3. Tambahkan repo asli sebagai upstream
git remote add upstream https://github.com/pemilik-asli/nama-proyek.git

# 4. Buat branch, buat perubahan, push
git switch -c fix/typo-readme
git add . && git commit -m "Perbaiki typo di README"
git push origin fix/typo-readme

# 5. Buka Pull Request di GitHub

Sinkronisasi Fork-mu

git fetch upstream
git switch main
git merge upstream/main
git push origin main

Perbedaan Fork vs Clone: Fork menyalin ke akun GitHub-mu (remote). Clone menyalin ke komputermu (lokal). Keduanya tidak mempengaruhi repo asli.

Tips untuk Mulai Berkontribusi

Kalau kamu baru ingin terjun ke open source:

Mulai dari yang kecil — perbaiki typo di dokumentasi, tambahkan komentar, perbaiki README. Jangan langsung menyerang bug paling kompleks.
Pelajari ekosistem proyek — baca README.md, CONTRIBUTING.md, dan riwayat commit untuk memahami konvensi yang digunakan.
Ikuti konvensi yang ada — cara menulis commit, penamaan branch, format PR description.

Aplikasi Git GUI: Tidak Harus Selalu Pakai Terminal

Mengetahui perintahnya membuatmu jadi developer yang lebih kuat — tapi kamu tidak harus mengetik di terminal setiap hari. Ada banyak aplikasi GUI (Graphical User Interface) yang memungkinkan kamu commit, branch, merge, dan stash hanya dengan klik, plus visualisasi riwayat repo yang mudah dipahami.

Berikut yang paling populer:

Aplikasi	Platform	Harga	Cocok Untuk
GitHub Desktop	Mac, Windows	Gratis	Pemula, pengguna GitHub
GitLens (ext. VS Code)	Semua OS	Gratis / Berbayar	Developer yang sehari-hari di VS Code/Cursor
GitKraken	Mac, Win, Linux	Gratis (terbatas) / Berbayar	Power user visual
Fork	Mac, Windows	Gratis trial / ~$50	Keseimbangan kecepatan & fitur
Sourcetree	Mac, Windows	Gratis	Pengguna Atlassian/Bitbucket

GitHub Desktop adalah yang paling sederhana — dibuat oleh GitHub, fokus pada hal-hal esensial.
GitLens adalah ekstensi VS Code yang menambahkan inline blame, visual commit graph, dan manajemen stash langsung di dalam editor-mu.
GitKraken punya tampilan commit graph yang keren dan fitur drag-and-drop untuk merge.
Fork menawarkan keseimbangan yang baik antara kecepatan dan fitur.
Sourcetree (buatan Atlassian) gratis dan kaya fitur, terutama kalau kamu pakai Bitbucket.

Meskipun pakai aplikasi GUI sehari-hari, memahami perintah dasarnya tetap penting — untuk debugging dan bekerja di server yang tidak punya GUI. Anggap aplikasi GUI sebagai lapisan produktivitas di atas pengetahuan Git-mu, bukan penggantinya.

Ringkasan

Konsep	Singkatnya
Repository	Gudang untuk file dan riwayat proyekmu
Commit	Snapshot tersimpan dengan pesan
Checkout	Kunjungi commit lama sementara
Reset	Hapus riwayat commit (hati-hati)
Revert	Undo commit dengan aman
Branch	Jalur pengembangan terpisah
Stash	Simpan sementara pekerjaan yang belum selesai
Worktree	Kerjakan dua branch sekaligus di folder berbeda
Merge	Gabungkan dua branch
Rebase	Putar ulang commit-mu di atas branch lain (khusus branch solo)
Pull Request	Permintaan formal untuk review dan merge
Fork	Salin repo orang lain ke akunmu
Clone	Salin repo ke komputer lokalmu

Git butuh waktu untuk terasa natural — tapi konsep-konsep di atas sudah mencakup 90% dari yang akan kamu pakai sehari-hari.

Mulai dari yang kecil, commit sesering mungkin, dan jangan takut membuat branch baru.

Satu commit pada satu waktu. 🚀

From OOP to SOLID: Everything You Need to Know in One Article

Sanudin — Sun, 24 May 2026 16:52:32 +0000

🌐 Read this post in Bahasa Indonesia here.

📝 A note on this article
This post is based on my personal study notes. The ideas, learning journey, and understanding are mine — I used AI to help structure and expand them into a proper blog format form.

Good code doesn't happen by accident. Behind every codebase that's a pleasure to work with, there's a set of ideas guiding how things are structured and connected.

This article covers that full journey — from what OOP is, how objects relate, what bad design looks like, and finally: the five SOLID principles that tie it all together.

Let's go.

Part 1: What Is OOP?

Object Oriented Programming (OOP) is a way of writing code that mirrors the real world. Instead of one long list of instructions, you group related data and behavior into objects.

🤖 Think of a robot toy. It has properties (color, height, battery) and behaviors (walk, talk, wave). In OOP, that robot is an object — and the blueprint used to build it is called a class.

Two key terms:

Class — the blueprint (template)
Object — a real instance built from the blueprint

The Four Pillars

Pillar	What it does
Inheritance	A child class inherits properties and behaviors from a parent class
Encapsulation	Internal data is hidden — only controlled access is allowed from outside
Abstraction	Complex internals are hidden; only what's needed is exposed
Polymorphism	The same action can behave differently depending on the object

Part 2: How Objects Relate

Objects don't exist in isolation. They connect, collaborate, and depend on each other — and the type of relationship matters.

Association

Two objects know about each other and can interact. Comes in three cardinalities:

One-to-one — one passport per person
One-to-many — one teacher, many students
Many-to-many — many students, many courses

Inside association, when one object "owns" another, the relationship is either:

Aggregation (loose) — the child survives without the parent. A backpack contains books, but the books still exist if you throw the backpack away.
Composition (tight) — the child cannot exist without the parent. A house has rooms; demolish the house, the rooms cease to exist.

Dependency

A temporary, usage-based relationship. One class uses another inside a method but doesn't hold onto it permanently. Weaker than association.

Generalization & Realization

Generalization — pulling shared traits from multiple classes into one superclass (inheritance)
Realization — a class implementing an interface, promising to fulfill a defined contract

Part 3: What Bad Design Looks Like

Before learning the rules, it helps to understand what you're guarding against. Robert C. Martin identified three symptoms of bad design:

🪨 Rigidity — the system is hard to change. Touch one thing, and a cascade of other things need updating. Developers become afraid to make changes.

🍪 Fragility — the system breaks in unexpected places when you make a change. You fix a bug in the payment module, and somehow the email notifications stop working.

🏗️ Immobility — useful components can't be reused. They're so entangled with their surroundings that extracting them would take longer than rewriting from scratch.

All three share the same root cause: poor management of dependencies between components.

Part 4: SOLID

SOLID is a set of five principles that directly address the problems above. Each one targets a specific failure mode.

S — Single Responsibility Principle

"A module should be responsible to one, and only one, actor."

Every class should have exactly one reason to change — it serves one actor (one group of stakeholders).

👨‍🍳 A restaurant worker who is simultaneously the chef, cashier, security guard, and delivery driver is a disaster waiting to happen. One change in one role disrupts all the others.

Split your classes. One responsibility each.

O — Open/Closed Principle

"A software artifact should be open for extension but closed for modification."

Add new behavior by extending — not by editing existing, working code.

🔌 A power strip lets you plug in new devices without rewiring the strip itself. That's OCP in action.

When requirements change, slot in new code alongside the old — don't rewrite what's already working.

L — Liskov Substitution Principle

"If S is a subtype of T, objects of type T may be replaced with objects of type S without altering program correctness."

A subclass must be fully substitutable for its parent class. Every promise the parent makes, the child must keep.

🤖 If the parent robot can cook, the child robot must be able to cook too — not throw an error or silently do nothing.

If your subclass has empty methods, stub implementations, or "not supported" throws — that's a Liskov violation.

I — Interface Segregation Principle

"Clients should not be forced to depend upon interfaces that they do not use."

Don't create fat interfaces that force classes to implement methods they don't need. Split interfaces into smaller, focused ones.

🍴 Don't give every restaurant customer a steak knife, soup spoon, chopsticks, and a fondue skewer when they only ordered soup.

Smaller interfaces = narrower dependencies = changes stay localized.

D — Dependency Inversion Principle

"High-level modules should not depend on low-level modules. Both should depend on abstractions."

Your business logic should not be hardwired to specific implementations. It should talk to interfaces — and the low-level details implement those interfaces.

🤖 Don't solder a spatula into the robot's arm. Give the arm a standard connector, and let tools be swapped in and out.

This is what makes infrastructure (databases, APIs, file systems) swappable without touching business logic.

Quick Reference: SOLID at a Glance

Principle	Problem it solves	Key question to ask
SRP	Classes doing too much	"Does this class serve more than one group of stakeholders?"
OCP	Editing old code to add features	"Can I add this as an extension instead of a modification?"
LSP	Broken inheritance hierarchies	"Can I swap the child for the parent without anything breaking?"
ISP	Fat interfaces with unused methods	"Is this class forced to implement something it doesn't need?"
DIP	Business logic locked to infrastructure	"Does my high-level code depend on a concrete class it shouldn't?"

Where to Start

If you're applying these for the first time:

Start with SRP — find your "doing too much" classes and split them
Check inheritance for LSP violations — empty methods are the warning sign
Introduce interfaces at infrastructure boundaries — that's DIP in practice

These principles aren't a checklist. They're questions to ask every time you sit down to write code.

Originally published as a series at: Part 1: What is OOP? | Part 2: When Objects Meet | Part 3: Why Bad Design Hurts | Part 4: SOLID

Dari OOP ke SOLID: Semua yang Perlu Kamu Tahu dalam Satu Artikel

Sanudin — Sun, 24 May 2026 16:50:29 +0000

🌐 Baca artikel ini dalam Bahasa Inggris di sini.

📝 Catatan tentang artikel ini
Artikel ini dibuat berdasarkan catatan belajar pribadi saya. Ide, perjalanan belajar, dan pemahamannya adalah milik saya — saya menggunakan AI untuk menyusun dan mengembangkannya menjadi artikel blog yang lebih muda dibaca.

Kode yang enak dibaca dan mudah diubah bukan kebetulan. Di balik setiap codebase yang menyenangkan untuk dikerjakan, ada sekumpulan ide yang memandu bagaimana semuanya disusun dan dihubungkan.

Artikel ini membahas perjalanan lengkap itu — mulai dari apa itu OOP, bagaimana objek saling berhubungan, seperti apa desain yang buruk, hingga akhirnya: lima prinsip SOLID yang menyatukan semuanya.

Yuk mulai.

Bagian 1: Apa Itu OOP?

Object Oriented Programming (OOP) adalah cara menulis kode yang mencerminkan dunia nyata. Alih-alih satu daftar panjang instruksi, kamu mengelompokkan data dan perilaku yang saling berkaitan ke dalam objek.

🤖 Bayangkan mainan robot. Robot punya properti (warna, tinggi, baterai) dan perilaku (berjalan, berbicara, melambaikan tangan). Dalam OOP, robot itu adalah objek — dan cetak biru yang digunakan untuk membuatnya disebut class.

Dua istilah kunci:

Class — cetak biru (template)
Object — wujud nyata yang dibuat dari cetak biru tersebut

Empat Pilar OOP

Pilar	Fungsinya
Inheritance	Class anak mewarisi properti dan perilaku dari class induk
Encapsulation	Data internal disembunyikan — akses dari luar hanya melalui jalur yang ditentukan
Abstraction	Kerumitan internal disembunyikan; hanya yang perlu digunakan saja yang ditampilkan
Polymorphism	Aksi yang sama bisa berperilaku berbeda tergantung pada objeknya

Bagian 2: Bagaimana Objek Saling Berhubungan

Objek tidak hidup sendiri-sendiri. Mereka terhubung, bekerja sama, dan saling bergantung — dan jenis hubungannya penting.

Asosiasi

Dua objek saling mengenal dan bisa berinteraksi. Ada tiga jenis kardinalitas:

One-to-one — satu orang satu paspor
One-to-many — satu guru, banyak murid
Many-to-many — banyak murid, banyak mata pelajaran

Dalam asosiasi, ketika satu objek "memiliki" objek lain, hubungannya bisa berupa:

Aggregation (longgar) — objek anak bisa hidup tanpa induknya. Tas ransel berisi buku, tapi bukunya tetap ada meski tasnya dibuang.
Composition (erat) — objek anak tidak bisa eksis tanpa induknya. Rumah punya kamar; hancurkan rumahnya, kamarnya ikut lenyap.

Dependency

Hubungan sementara berbasis pemakaian. Satu class memakai class lain di dalam sebuah method, tapi tidak menyimpannya secara permanen. Lebih lemah dari asosiasi.

Generalization & Realization

Generalization — mengangkat sifat-sifat yang sama dari beberapa class ke satu superclass (pewarisan)
Realization — sebuah class mengimplementasikan interface, berjanji untuk memenuhi kontrak yang sudah didefinisikan

Bagian 3: Seperti Apa Desain yang Buruk?

Sebelum belajar aturannya, penting untuk memahami apa yang sedang kita hindari. Robert C. Martin mengidentifikasi tiga gejala desain yang buruk:

🪨 Rigidity (Kekakuan) — sistem susah diubah. Sentuh satu hal, dan banyak hal lain ikut perlu diperbarui. Developer jadi takut untuk melakukan perubahan.

🍪 Fragility (Kerapuhan) — sistem rusak di tempat yang tidak terduga saat kamu melakukan perubahan. Kamu memperbaiki bug di modul pembayaran, tiba-tiba notifikasi email berhenti berfungsi.

🏗️ Immobility (Ketidakmampuan Dipindahkan) — komponen yang berguna tidak bisa dipakai ulang. Mereka terlalu kusut dengan sekitarnya sehingga mencabutnya butuh lebih lama dari menulis ulang dari awal.

Ketiganya punya akar penyebab yang sama: pengelolaan dependensi antar komponen yang buruk.

Bagian 4: SOLID

SOLID adalah lima prinsip yang secara langsung mengatasi masalah di atas. Masing-masing menargetkan kegagalan desain yang spesifik.

S — Single Responsibility Principle

"Sebuah modul harus bertanggung jawab pada satu, dan hanya satu, aktor."

Setiap class harus punya tepat satu alasan untuk berubah — ia melayani satu aktor (satu kelompok stakeholder).

👨‍🍳 Seorang pekerja restoran yang sekaligus menjadi koki, kasir, satpam, dan pengantar makanan adalah bencana yang menunggu terjadi. Perubahan di satu peran mengganggu semua peran lainnya.

Pisahkan class-mu. Satu tanggung jawab per class.

O — Open/Closed Principle

"Artefak perangkat lunak harus terbuka untuk ditambahkan, tapi tertutup untuk dimodifikasi."

Tambahkan perilaku baru dengan cara memperluas — bukan mengedit kode lama yang sudah berjalan.

🔌 Stop kontak memungkinkan kamu mencolokkan perangkat baru tanpa perlu membongkar kabelnya. Itulah OCP dalam praktik.

Ketika kebutuhan berubah, tambahkan kode baru di samping yang lama — jangan tulis ulang yang sudah berjalan.

L — Liskov Substitution Principle

"Jika S adalah subtipe dari T, objek bertipe T bisa digantikan dengan objek bertipe S tanpa mengubah kebenaran program."

Sebuah subclass harus sepenuhnya bisa menggantikan class induknya. Setiap janji yang dibuat induk, harus dipenuhi oleh anak.

🤖 Kalau robot induk bisa memasak, robot anak juga harus bisa memasak — bukan melempar error atau diam saja tanpa melakukan apa-apa.

Kalau subclass-mu punya method kosong, implementasi stub, atau melempar "not supported" — itu pelanggaran Liskov.

I — Interface Segregation Principle

"Client tidak boleh dipaksa bergantung pada interface yang tidak mereka gunakan."

Jangan buat interface besar yang memaksa class mengimplementasikan method yang tidak mereka butuhkan. Pecah interface menjadi bagian-bagian kecil yang lebih fokus.

🍴 Jangan berikan setiap pelanggan restoran pisau steak, sendok sup, sumpit, dan tusuk fondue ketika mereka hanya memesan sup.

Interface yang lebih kecil = dependensi yang lebih sempit = perubahan tetap terlokalisir.

D — Dependency Inversion Principle

"Modul tingkat tinggi tidak boleh bergantung pada modul tingkat rendah. Keduanya harus bergantung pada abstraksi."

Logika bisnis tidak boleh terkait langsung dengan implementasi spesifik. Ia harus bicara dengan interface — dan detail tingkat rendah yang mengimplementasikan interface tersebut.

🤖 Jangan solder spatula ke tangan robot. Beri tangannya konektor standar, dan biarkan alat-alatnya bisa diganti-ganti.

Inilah yang membuat infrastruktur (database, API, file system) bisa diganti tanpa menyentuh logika bisnis.

Ringkasan Cepat: SOLID Sekilas

Prinsip	Masalah yang diatasi	Pertanyaan kuncinya
SRP	Class mengerjakan terlalu banyak hal	"Apakah class ini melayani lebih dari satu kelompok stakeholder?"
OCP	Mengedit kode lama untuk menambah fitur	"Bisakah ini ditambahkan sebagai ekstensi, bukan modifikasi?"
LSP	Hirarki pewarisan yang rusak	"Bisakah anak menggantikan induk tanpa ada yang rusak?"
ISP	Interface gemuk dengan method yang tidak dipakai	"Apakah class ini dipaksa mengimplementasikan sesuatu yang tidak dibutuhkan?"
DIP	Logika bisnis terikat ke infrastruktur	"Apakah kode tingkat tinggi bergantung pada class konkret yang seharusnya tidak?"

Mulai dari Mana?

Kalau kamu baru pertama kali menerapkan ini:

Mulai dengan SRP — cari class yang "mengerjakan terlalu banyak" dan pecah
Periksa pewarisan untuk pelanggaran LSP — method kosong adalah tanda peringatannya
Tambahkan interface di batas infrastruktur — itulah DIP dalam praktik

Prinsip-prinsip ini bukan checklist. Mereka adalah pertanyaan yang perlu kamu ajukan setiap kali duduk untuk menulis kode.

Originally published as a series at: Part 1: What is OOP? | Part 2: When Objects Meet | Part 3: Why Bad Design Hurts | Part 4: SOLID

DEV Community: Sanudin

Meta Tag HTML — Catatan Pribadi

Pengaturan Dasar Dokumen dan Responsif

SEO dan Indexing Dasar

Social Card (OG + X)

GEO / AI Crawler

JSON-LD untuk identitas — kenapa ini penting

Header Keamanan

Content Security Policy — fungsi masing-masing bagiannya

Referrer Policy — apa yang sebenarnya dikirim oleh strict-origin-when-cross-origin

PWA / Browser

Tabel Referensi

Yang Saya Pakai

HTML Meta Tags: My Reference Notes

Document Core and Responsive Setup

Basic SEO and Indexing

Social Cards (OG + X)

GEO / AI Crawlers

JSON-LD for identity — why I bother with this

Security Headers

Content Security Policy — what each part is actually doing

Referrer Policy — what strict-origin-when-cross-origin actually sends

PWA / Browser

Quick Table

What I Actually Use

Git & Collaboration: A Beginner's Guide (With Real Analogies)

What Is Git?

Repository: Your Project's Warehouse

Commit: Your Project's Save Point

Checkout, Reset, Revert: Traveling Through Time

git checkout — Visit the Past (Temporarily)

git reset — Erase History

git revert — The Safe Undo

Branches: Parallel Universes for Your Code

Stash: The Pause Button for Unfinished Work

Worktree: No Stash Needed

Merge & Pull Requests: Bringing It All Together

Merge Options

Handling Conflicts

Rebase: A Cleaner Alternative to Merge

Code Reviews: The Quality Gate

Fork & Clone: Contributing Without Access

Keeping Your Fork Synced

Git GUI Apps: You Don't Have to Type Everything

Summary

Git & Kolaborasi: Panduan untuk Pemula (Lengkap dengan Analogi)

Apa Itu Git?

Repository: Gudang Proyekmu

Commit: Save Point Proyekmu

Checkout, Reset, Revert: Mesin Waktu Git

git checkout — Kunjungi Masa Lalu (Sementara)

git reset — Hapus Riwayat

git revert — Undo yang Aman

Branch: Jalur Paralel untuk Kode

Stash: Tombol Pause untuk Pekerjaan yang Belum Selesai

Worktree: Tanpa Perlu Stash

Merge & Pull Request: Menyatukan Pekerjaan

Tiga Opsi Merge

Menangani Conflict

Rebase: Alternatif yang Lebih Bersih dari Merge

Code Review: Pintu Gerbang Kualitas

Fork & Clone: Berkontribusi Tanpa Akses

Sinkronisasi Fork-mu

Tips untuk Mulai Berkontribusi

Aplikasi Git GUI: Tidak Harus Selalu Pakai Terminal

Ringkasan

From OOP to SOLID: Everything You Need to Know in One Article

Part 1: What Is OOP?

The Four Pillars

Part 2: How Objects Relate

Association

Dependency

Generalization & Realization

Part 3: What Bad Design Looks Like

Part 4: SOLID

S — Single Responsibility Principle

O — Open/Closed Principle

L — Liskov Substitution Principle

I — Interface Segregation Principle

D — Dependency Inversion Principle

Referrer Policy — apa yang sebenarnya dikirim oleh `strict-origin-when-cross-origin`

Referrer Policy — what `strict-origin-when-cross-origin` actually sends

`git checkout` — Visit the Past (Temporarily)

`git reset` — Erase History

`git revert` — The Safe Undo

`git checkout` — Kunjungi Masa Lalu (Sementara)

`git reset` — Hapus Riwayat

`git revert` — Undo yang Aman