GitHub bukan sekadar tempat menyimpan kode. Ia adalah alun-alun tempat perangkat lunak dunia dibangun secara terbuka, tempat seorang pelajar di kamar kos bisa berkontribusi ke proyek yang dipakai jutaan orang, dan tempat rekruter melihat siapa Anda sebenarnya sebagai pembangun. Buku ini mengajak Anda menguasainya dari nol.

Saya menulis buku ini karena terlalu banyak orang berbakat menganggap GitHub itu menakutkan — deretan perintah aneh, istilah asing seperti rebase, pipeline, dan deploy key, serta rasa takut "merusak sesuatu". Padahal, begitu Anda memahami model mentalnya, GitHub justru menjadi jaring pengaman: setiap perubahan tercatat, setiap kesalahan bisa dibatalkan, dan setiap kolaborasi punya jejak yang jelas.

Yang membuat buku ini berbeda: kita tidak berhenti di "cara commit". Kita berjalan sampai ke ujung yang jarang diajarkan pemula — membangun profil portofolio yang bercerita, menyalakan GitHub Actions untuk menguji dan membangun kode secara otomatis, lalu deploy ke server (VPS) lewat SSH hanya dengan sekali git push. Inilah rangkaian yang mengubah Anda dari "orang yang bisa Git" menjadi "orang yang bisa mengirim perangkat lunak ke dunia".

Talk is cheap. Show me the code.

Linus Torvalds, pencipta Git dan Linux

Setiap bab berdiri sendiri namun tersusun menaik. Bab 1–5 adalah fondasi (kenapa, Git dasar, repo, lisensi, README). Bab 6–9 membangun kehadiran Anda (profil, Pages, organisasi, kolaborasi). Bab 10–13 adalah otomasi dan pengiriman (Actions, testing, SSH, deploy). Bab 14 menutup dengan keamanan, dan Bab 15 menjelaskan bagaimana repositori yang rapi juga lebih mudah dipahami oleh asisten AI. Selamat membangun.

Buku ini ditulis untuk semua level. Jika Anda benar-benar baru, baca berurutan dan praktikkan tiap perintah di terminal Anda sendiri — GitHub gratis untuk memulai. Jika Anda sudah terbiasa Git tetapi ingin menaikkan level (CI/CD, deploy, profil), lompat langsung ke bab yang relevan lewat Daftar Isi di kiri.

Konvensi penulisan

• Blok kode gelap berisi perintah yang bisa Anda salin (ada tombol Salin di pojoknya). Baris diawali # adalah komentar, bukan bagian perintah.
• Teks seperti <nama-anda> adalah placeholder — ganti dengan nilai Anda sendiri, termasuk tanda kurung siku.
• Kotak hijau berisi tips, kuning peringatan, merah bahaya, ungu catatan khusus AI.
• Label verifikasi ke dokumentasi resmi GitHub menandai hal yang cepat berubah (harga, batas kuota, nama menu). Anggap teks di sini sebagai peta, bukan sumber kebenaran terakhir.

Bayangkan dua orang dengan kemampuan koding setara. Yang satu menyimpan proyeknya di folder laptop; yang lain membangunnya terbuka di GitHub selama setahun. Saat melamar kerja, yang kedua punya bukti: riwayat commit, proyek yang bisa dibuka, kontribusi yang bisa ditelusuri. GitHub mengubah kerja Anda dari cerita menjadi bukti.

GitHub adalah platform hosting untuk repositori Git plus lapisan kolaborasi di atasnya: halaman proyek, pelacak isu, tinjauan kode, otomasi, dan hosting web. Di 2026, ia adalah standar de facto tempat sebagian besar perangkat lunak sumber terbuka dunia berada, dan tempat banyak tim (dan individu) memamerkan karya mereka.

Portofolio yang Hidup

CV tradisional mengatakan "saya bisa React". Profil GitHub menunjukkannya: repositori nyata, kode yang bisa dibaca, README yang menjelaskan keputusan desain, dan grafik kontribusi yang memperlihatkan konsistensi. Bagi banyak perekrut teknis, tautan GitHub Anda lebih berbobot daripada satu halaman PDF.

Portofolio di GitHub bersifat kumulatif. Setiap proyek kecil yang Anda selesaikan menambah lapisan. Setahun dari sekarang, profil Anda akan menjadi arsip perjalanan belajar yang tak bisa dipalsukan — dan itu jauh lebih meyakinkan daripada klaim di wawancara.

Kolaborasi & Deploy

Kekuatan kedua GitHub adalah kolaborasi terstruktur. Lewat Pull Request, perubahan diusulkan, ditinjau, didiskusikan, lalu digabung — semua tercatat. Ini adalah bahasa universal tim perangkat lunak modern; menguasainya berarti Anda bisa langsung produktif di tim mana pun.

Kekuatan ketiga, yang sering terlewat pemula: GitHub bisa menjalankan kode Anda. Lewat GitHub Actions, setiap push bisa memicu pengujian otomatis, pembangunan aplikasi, dan pengiriman ke server produksi. Repositori Anda berubah dari lemari arsip menjadi pabrik yang bekerja sendiri. Inti buku ini — Bab 10 sampai 13 — adalah tentang menyalakan pabrik itu.

Given enough eyeballs, all bugs are shallow.

Eric S. Raymond, "The Cathedral and the Bazaar"

Apa yang bisa dilakukan gratis

Akun personal GitHub gratis sudah mencakup repositori publik dan privat tanpa batas, GitHub Actions dengan kuota menit bulanan, GitHub Pages untuk hosting statis, dan fitur kolaborasi inti. Ini lebih dari cukup untuk membangun portofolio serius dan menjalankan CI/CD untuk proyek pribadi.

Git adalah mesin di balik GitHub: sistem kontrol versi yang mencatat setiap perubahan sebagai "snapshot". GitHub adalah tempat snapshot itu disimpan dan dibagikan. Anda tidak perlu menguasai seluruh Git untuk produktif — sepuluh perintah dalam bab ini menutupi 95% pekerjaan harian.

Sebelum apa pun, pastikan Git terpasang dan perkenalkan diri Anda ke Git. Nama dan email ini akan menempel di setiap commit.

Salin# cek versi (kalau belum ada, unduh dari git-scm.com)
git --version

# identitas Anda (sekali saja, global)
git config --global user.name "Nama Anda"
git config --global user.email "email@anda.com"

# branch default bernama main (standar modern)
git config --global init.defaultBranch main

Alur Kerja Git

Model mental Git punya tiga "area": working directory (file yang Anda edit), staging area (perubahan yang dipilih untuk commit berikutnya), dan repository (riwayat commit permanen). Anda memindahkan perubahan dari kiri ke kanan: edit → git add → git commit → git push.

Sepuluh perintah harian

Siklus commit pertama Anda

Salin# mulai repo baru di folder kosong
git init
echo "# Proyek Saya" > README.md
git add .
git commit -m "chore: commit pertama"

# hubungkan ke repo GitHub yang sudah dibuat lewat web
git remote add origin git@github.com:namaanda/proyek-saya.git
git branch -M main
git push -u origin main

Branch, Merge & Pull Request

Cabang (branch) memungkinkan Anda mengerjakan fitur baru tanpa mengganggu kode utama. Anda "cabang" dari main, bekerja bebas, lalu menggabungkannya kembali saat siap. Di GitHub, penggabungan biasanya lewat Pull Request (PR) — sebuah usulan perubahan yang bisa ditinjau sebelum digabung.

Salin# buat & pindah ke cabang baru sekaligus
git switch -c feature/login

# ...kerjakan, add, commit seperti biasa...
git push -u origin feature/login

# lalu buka Pull Request lewat web GitHub,
# atau dengan GitHub CLI:
gh pr create --fill

Version control is the single most important tool a developer can learn. Everything else is negotiable.

Prinsip umum rekayasa perangkat lunak

Repository (atau "repo") adalah unit dasar di GitHub: satu proyek, satu wadah. Di dalamnya ada kode, riwayat, isu, pengaturan, dan halaman proyek. Bab ini membahas cara membuat repo yang sejak awal terlihat profesional — karena kesan pertama pengunjung terbentuk dalam sepuluh detik.

Membuat Repo

Ada dua jalan. Lewat web: klik tombol New di dashboard, isi nama, deskripsi, pilih visibilitas, centang "Add a README", pilih .gitignore dan lisensi. Lewat terminal dengan GitHub CLI (gh): satu perintah membuat repo sekaligus menghubungkannya.

Salin# dengan GitHub CLI — buat repo publik + README + push folder saat ini
gh repo create proyek-saya --public --source=. --push --description "Deskripsi singkat"

# atau repo privat kosong
gh repo create catatan-pribadi --private --clone

Public vs Private

Setiap repo bersifat public (siapa pun bisa melihat) atau private (hanya Anda dan kolaborator yang diundang). Keduanya gratis dan tak terbatas di akun personal. Pilihan bergantung pada tujuan.

.gitignore & Struktur

File .gitignore memberi tahu Git file/folder mana yang tidak boleh dilacak: dependensi (node_modules/), hasil build (dist/), rahasia (.env), dan sampah sistem (.DS_Store). GitHub menyediakan template siap pakai per bahasa.

Salin# .gitignore — contoh proyek Node.js
node_modules/
dist/
build/
.env
.env.local
*.log
.DS_Store
.vscode/
coverage/

Struktur repo yang rapi

Struktur yang konsisten membuat repo mudah dinavigasi oleh manusia maupun AI. Pola umum yang aman:

Description & Topics

Dua metadata kecil yang berdampak besar pada penemuan repo Anda: Description (satu kalimat di bawah nama repo) dan Topics (label seperti react, rest-api, machine-learning). Topics membuat repo muncul di pencarian dan halaman topik GitHub. Isi keduanya lewat tombol gerigi di sisi kanan halaman repo, atau via CLI.

Salingh repo edit --description "API katalog produk dengan Express + PostgreSQL" \
  --add-topic nodejs --add-topic express --add-topic rest-api

Tanpa lisensi, kode publik Anda secara hukum "hak cipta penuh" — artinya orang lain tidak boleh menggunakannya, meski terlihat di GitHub. Lisensi adalah izin yang Anda berikan. Memilihnya adalah keputusan sadar tentang seberapa bebas orang lain boleh memakai karya Anda.

Jenis Lisensi

Lisensi open source dibagi dua kubu besar: permissive (bebas, sedikit syarat) dan copyleft (bebas, tapi turunannya wajib ikut terbuka). Berikut yang paling umum.

Free software is a matter of liberty, not price. Think "free speech," not "free beer."

Richard Stallman, Free Software Foundation

Memilih & Menambah

Aturan praktis: jika Anda ingin sesedikit mungkin gesekan dan orang boleh memakai kode Anda di mana saja (termasuk produk komersial tertutup), pilih MIT. Jika Anda peduli perlindungan paten untuk proyek yang lebih besar, pilih Apache-2.0. Jika Anda ingin semua turunan tetap open source, pilih GPL-3.0.

Cara menambah lisensi

Paling mudah: saat membuat repo, pilih dari dropdown lisensi. Untuk repo yang sudah ada, GitHub menyediakan alur otomatis — klik Add file → Create new file, ketik LICENSE sebagai nama file, dan tombol "Choose a license template" akan muncul. Atau lakukan manual:

Salin# dengan GitHub CLI, buat repo langsung dengan lisensi MIT
gh repo create proyek-saya --public --license mit

# atau tambah manual: buat file LICENSE, tempel teks resmi,
# ganti tahun & nama, lalu commit
git add LICENSE
git commit -m "docs: tambah lisensi MIT"
git push

Teks resmi setiap lisensi tersedia di choosealicense.com — situs yang dikelola GitHub untuk membantu memilih. Salin teksnya utuh; jangan mengubah isi selain baris tahun dan nama pemegang hak cipta.

README.md adalah halaman depan repo Anda — hal pertama yang dibaca siapa pun yang mendarat di sana. README yang baik menjawab tiga pertanyaan dalam sepuluh detik: Ini apa? Kenapa saya peduli? Bagaimana cara memakainya? README yang buruk membuat pengunjung menutup tab.

Struktur & Badge

README yang efektif mengikuti urutan yang bisa ditebak. Anda tidak wajib memakai semuanya, tapi urutannya penting: yang paling menarik di atas.

1. Judul + satu kalimat — nama proyek dan penjelasan sebaris.
2. Badge — status build, versi, lisensi (dijelaskan di bawah).
3. Demo / screenshot — satu gambar atau GIF sering lebih kuat dari paragraf.
4. Fitur — daftar poin apa yang bisa dilakukan.
5. Instalasi — langkah menjalankan di komputer sendiri.
6. Pemakaian — contoh kode/perintah nyata.
7. Kontribusi — cara orang lain ikut membantu.
8. Lisensi — satu baris menyebut lisensinya.

Badge: sinyal kepercayaan visual

Badge adalah lencana kecil dari layanan seperti shields.io yang menampilkan status: apakah build lulus, versi berapa, lisensi apa. Mereka murni gambar dari URL — Anda cukup menempel Markdown. Formatnya: ![alt](url-badge).

Salin# badge statis dari shields.io — pola: label-pesan-warna
![License](https://img.shields.io/badge/license-MIT-blue)
![Node](https://img.shields.io/badge/node-%3E%3D20-green)

# badge dinamis — status GitHub Actions (otomatis update)
![CI](https://github.com/namaanda/repo/actions/workflows/ci.yml/badge.svg)

Generator README Proyek

Untuk mempercepat, gunakan generator di bawah. Isi kolomnya, klik Hasilkan, lalu Salin. Tempelkan hasilnya ke file README.md di repo Anda. Semua berjalan di browser Anda — tidak ada data yang dikirim ke mana pun.

Klik "Hasilkan README" untuk melihat hasil…

Documentation is a love letter that you write to your future self.

Damian Conway

Ada trik yang tidak diketahui banyak orang: jika Anda membuat repositori dengan nama yang persis sama dengan username Anda (misalnya repo bernama namaanda untuk user namaanda), README di dalamnya akan tampil sebagai spanduk di halaman profil Anda. Inilah "Profile README" — kartu nama digital Anda.

Anatomi Profil Keren

Halaman profil yang kuat memadukan beberapa elemen: avatar dan bio yang jelas, Profile README yang bercerita, deretan pinned repositories (enam proyek terbaik yang Anda pilih tampilkan), badge keahlian, kartu statistik, dan tentu saja contribution graph hijau yang memperlihatkan ritme kerja Anda.

Contribution Graph: Konsistensi yang Etis

Grafik kontribusi memetakan aktivitas Anda: setiap kotak adalah satu hari, warnanya makin hijau terang seiring banyaknya commit, PR, dan isu hari itu. Grafik yang "hidup" memberi kesan Anda pembangun yang konsisten — dan konsistensi memang bernilai.

Cara etis membuat grafik konsisten: commit kecil tapi rutin dari pekerjaan nyata. Belajar sesuatu → tulis catatan di repo → commit. Selesaikan satu fungsi → commit. Ikut proyek open source → PR. Konsistensi tumbuh sebagai efek samping kebiasaan belajar, bukan sebagai tujuan yang dikarang.

We are what we repeatedly do. Excellence, then, is not an act, but a habit.

Will Durant, meringkas Aristoteles

Stats cards & pinned strategis

Banyak profil menambahkan kartu statistik dinamis (jumlah bintang, bahasa teratas, streak) dari layanan pihak ketiga yang menghasilkan gambar SVG. Berhati-hatilah memilih layanan yang tepercaya. Untuk pinned repos, pilih enam yang bercerita: proyek terbaik, yang paling beragam bahasanya, dan yang README-nya paling rapi — bukan sekadar yang terbaru.

Generator Profile README

Generator ini menghasilkan Profile README yang menonjol: header sapaan, badge keahlian dari shields.io, bagian skill, tautan sosial, dan placeholder kartu statistik. Isi, hasilkan, salin, lalu tempel ke repo yang bernama sama dengan username Anda.

Klik "Hasilkan Profil" untuk melihat hasil…

GitHub Pages menghosting situs web statis langsung dari repositori Anda — gratis, dengan HTTPS, dan URL namaanda.github.io. Ini cara termudah menaruh portofolio, dokumentasi, atau landing page proyek di internet tanpa membayar hosting.

Hosting Gratis untuk Portofolio

Pages cocok untuk apa pun yang "statis": HTML/CSS/JS biasa, atau hasil build dari framework seperti Astro, Vite, Next (mode ekspor statis), Hugo, atau Jekyll. Yang tidak bisa: backend/server-side (butuh server nyata — lihat Bab 13).

Cara tercepat: satu file HTML

1. Buat repo publik, misalnya portofolio.
2. Tambahkan file index.html.
3. Buka Settings → Pages, pada "Source" pilih branch main dan folder / (root), simpan.
4. Tunggu semenit; situs Anda hidup di https://namaanda.github.io/portofolio/.

Untuk situs hasil build (Vite/Astro/dll)

Framework modern menghasilkan folder statis (biasanya dist/). Cara terbersih di 2026 adalah men-deploy lewat GitHub Actions resmi. Contoh workflow untuk situs Vite:

Salin# .github/workflows/pages.yml
name: Deploy Pages
on: { push: { branches: [main] } }
permissions: { contents: read, pages: write, id-token: write }
jobs:
  build-deploy:
    runs-on: ubuntu-latest
    environment: github-pages
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with: { node-version: "20" }
      - run: npm ci && npm run build
      - uses: actions/upload-pages-artifact@v3
        with: { path: ./dist }
      - uses: actions/deploy-pages@v4

Akun personal cukup untuk perjalanan solo. Begitu Anda bekerja dengan tim, komunitas, atau startup, Organization menjadi wadah bersama: repositori dimiliki organisasi (bukan satu orang), anggota dikelompokkan ke tim, dan izin diatur berlapis.

Tim, Roles & Permissions

Membuat organisasi gratis: dari menu + di kanan atas, pilih New organization, pilih paket Free, beri nama (misalnya sainskerta), undang anggota. Repositori yang dibuat di dalamnya dimiliki organisasi — jika satu orang keluar, proyek tetap aman.

Peran di tingkat organisasi

Tim dan izin per-repo

Di dalam org, Anda membuat tim (misalnya @sainskerta/backend, @sainskerta/design). Tim bisa bertingkat (tim induk & anak) dan disebut langsung dalam diskusi/PR. Setiap tim atau individu mendapat tingkat akses ke repo:

If you want to go fast, go alone. If you want to go far, go together.

Pepatah, sering dikutip di komunitas open source

Kode hanyalah setengah dari perangkat lunak; setengah lainnya adalah percakapan tentang kode. GitHub menyediakan alat terstruktur untuk percakapan itu: Issues untuk melacak pekerjaan, Pull Request untuk mengusulkan perubahan, Projects untuk mengorganisir, dan Discussions untuk obrolan yang lebih longgar.

Issues

Issue adalah tiket: laporan bug, permintaan fitur, atau tugas. Setiap issue punya judul, deskripsi (Markdown penuh), label, assignee, milestone, dan komentar. Ini adalah daftar tugas bersama yang bisa dirujuk dari commit dan PR.

Salin# buat issue dari terminal
gh issue create --title "Login gagal saat email kosong" \
  --body "Langkah reproduksi: ...\nEkspektasi: ...\nAktual: ..." \
  --label bug

# commit yang menutup issue #12 otomatis saat di-merge ke main
git commit -m "fix: validasi email kosong (closes #12)"

Pull Request & Review

Pull Request adalah jantung kolaborasi GitHub: usulan menggabungkan perubahan dari satu branch ke branch lain, lengkap dengan tampilan diff (baris hijau ditambah, merah dihapus), diskusi baris-per-baris, hasil pemeriksaan CI, dan tombol merge. Sebelum merge, rekan bisa review: menyetujui (Approve), meminta perubahan (Request changes), atau sekadar berkomentar.

Alur review yang sehat

1. Penulis membuka PR kecil dan fokus (satu tujuan). PR raksasa sulit ditinjau.
2. Deskripsi PR menjelaskan apa dan kenapa, bukan hanya bagaimana.
3. CI berjalan otomatis; reviewer menunggu hijau sebelum menilai.
4. Reviewer memberi umpan balik spesifik dan sopan; penulis merespons tiap komentar.
5. Setelah disetujui & CI hijau, PR di-merge. Branch fitur boleh dihapus.

Projects (Kanban) & Discussions

Projects adalah papan perencanaan yang menghubungkan Issues dan PR ke tampilan visual: papan Kanban (kolom "Todo → In Progress → Done"), tabel dengan bidang kustom (prioritas, estimasi), atau linimasa. Kartu di papan adalah issue/PR nyata, jadi memindahkannya mencerminkan kemajuan asli.

Discussions adalah forum di dalam repo — untuk tanya-jawab, ide, pengumuman, dan tanya komunitas yang tidak cocok jadi issue (karena bukan bug/tugas). Cocok untuk proyek open source dengan banyak pengguna. Aktifkan lewat Settings → Features.

The most important property of a program is whether it accomplishes the intention of its user.

C.A.R. Hoare

Inilah bab yang mengubah GitHub dari lemari arsip menjadi pabrik. GitHub Actions menjalankan kode Anda di server GitHub sebagai respons atas peristiwa — paling sering git push. CI/CD (Continuous Integration / Continuous Delivery) adalah praktik yang dibangun di atasnya: setiap perubahan otomatis diuji, dibangun, dan (jika lulus) dikirim.

Anatomi Workflow YAML

Workflow adalah file .yml di folder .github/workflows/. Strukturnya berlapis: workflow berisi jobs, tiap job berisi steps, tiap step menjalankan perintah atau memakai action siap pakai (uses:).

Workflow paling minimal

Salin# .github/workflows/hello.yml
name: Hello CI
on: [push]
jobs:
  sapa:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4          # ambil kode repo
      - run: echo "Halo dari server GitHub!"
      - run: ls -la                         # perintah shell apa pun

Contoh Workflow: Lint + Test + Build

Workflow nyata untuk proyek Node.js: pasang dependensi, jalankan linter, jalankan test, lalu build. Jika salah satu step gagal, workflow berhenti dan PR ditandai merah.

Salin# .github/workflows/ci.yml
name: CI
on:
  push: { branches: [main] }
  pull_request: { branches: [main] }
jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with: { node-version: "20", cache: "npm" }
      - run: npm ci                # install bersih dari lockfile
      - run: npm run lint          # cek gaya kode
      - run: npm test              # jalankan unit test
      - run: npm run build         # pastikan bisa dibangun

Saat workflow berjalan, tab Actions di repo menampilkan setiap langkah dengan ikon: lingkaran kuning berputar (sedang jalan), ceklis hijau (lulus), atau silang merah (gagal). Klik langkah mana pun untuk melihat log lengkapnya.

Secrets & Variables

Workflow sering butuh nilai rahasia: token deploy, kata sandi database, kunci API. Jangan pernah menuliskannya langsung di file YAML (yang tersimpan di repo). Simpan sebagai Secrets di Settings → Secrets and variables → Actions. Nilainya terenkripsi dan tersamar di log.

Salinsteps:
  - run: ./deploy.sh
    env:
      # diambil dari Secrets, tidak pernah terlihat di kode
      API_TOKEN: ${{ secrets.API_TOKEN }}
      DB_URL: ${{ secrets.DATABASE_URL }}
      # Variables (non-rahasia) pakai vars.*
      APP_ENV: ${{ vars.APP_ENV }}

If it hurts, do it more often. Bring the pain forward.

Jez Humble & David Farley, "Continuous Delivery"

Test otomatis di CI adalah jaring pengaman yang tak pernah lelah. Setiap kali seseorang mengusulkan perubahan, seluruh test berjalan dalam hitungan detik dan memberi tahu: aman digabung, atau ada yang rusak. Ini mengubah "semoga tidak merusak apa-apa" menjadi kepastian yang bisa diverifikasi.

Menjalankan test di CI hanya butuh satu step: perintah test proyek Anda. Yang penting adalah kode keluaran (exit code) — jika test gagal, perintah mengembalikan kode bukan-nol, dan Actions menandai job sebagai gagal secara otomatis.

Salinsteps:
  - uses: actions/checkout@v4
  - uses: actions/setup-node@v4
    with: { node-version: "20" }
  - run: npm ci
  # jalankan test + hasilkan laporan cakupan (coverage)
  - run: npm test -- --coverage

Matrix & Badge Status

Strategy matrix menjalankan job yang sama di banyak kombinasi sekaligus — misalnya menguji di Node 18, 20, dan 22, di Linux dan Windows. Jika kode Anda harus jalan di banyak lingkungan, matrix membuktikannya dalam satu workflow.

Salinjobs:
  test:
    runs-on: ${{ matrix.os }}
    strategy:
      matrix:
        os: [ubuntu-latest, windows-latest]
        node: ["18", "20", "22"]
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with: { node-version: ${{ matrix.node }} }
      - run: npm ci && npm test
      # menghasilkan 2 x 3 = 6 job paralel

Badge status di README

Setiap workflow otomatis menyediakan badge status yang selalu menunjukkan kondisi terkini branch utama. Tempelkan di README agar pengunjung langsung melihat kesehatan proyek. Formatnya baku:

Salin# pola: /{user}/{repo}/actions/workflows/{file}/badge.svg
![CI](https://github.com/namaanda/toko-online-api/actions/workflows/ci.yml/badge.svg)

Testing shows the presence, not the absence of bugs.

Edsger W. Dijkstra

SSH (Secure Shell) adalah cara Anda membuktikan identitas ke GitHub tanpa mengetik kata sandi tiap kali. Alih-alih sandi, Anda memakai sepasang kunci: kunci privat yang disimpan rahasia di komputer Anda, dan kunci publik yang Anda titipkan ke GitHub. Keduanya cocok seperti gembok dan anak kunci.

Generate & Tambah Key

Alurnya tiga langkah: buat pasangan kunci, tambahkan kunci publik ke akun GitHub, lalu uji koneksinya. Kunci privat tidak pernah meninggalkan komputer Anda.

Salin# 1. buat kunci Ed25519 (modern & aman). Ganti email Anda.
ssh-keygen -t ed25519 -C "email@anda.com"
#   tekan Enter untuk lokasi default (~/.ssh/id_ed25519)
#   beri passphrase untuk lapisan aman ekstra (opsional tapi disarankan)

# 2. salin isi KUNCI PUBLIK (.pub — yang boleh dibagikan)
cat ~/.ssh/id_ed25519.pub
#   di macOS: pbcopy < ~/.ssh/id_ed25519.pub
#   di Windows (Git Bash): clip < ~/.ssh/id_ed25519.pub

# 3. tempel ke GitHub: Settings → SSH and GPG keys → New SSH key

# 4. uji koneksi
ssh -T git@github.com
#   sukses bila muncul: "Hi namaanda! You've successfully authenticated..."

Clone via SSH

Setelah kunci terpasang, gunakan URL SSH (diawali git@github.com:) alih-alih HTTPS. Anda tidak akan diminta sandi lagi. Di halaman repo, tombol Code menyediakan pilihan SSH.

Salin# clone via SSH (perhatikan format: git@host:user/repo.git)
git clone git@github.com:namaanda/toko-online-api.git

# ubah repo lama dari HTTPS ke SSH
git remote set-url origin git@github.com:namaanda/toko-online-api.git

# cek remote sekarang
git remote -v

Security is always excessive until it's not enough.

Robbie Sinclair

Inilah puncak buku ini: satu git push ke main memicu GitHub Actions yang masuk ke server Anda lewat SSH, menarik kode terbaru, dan me-restart aplikasi. Tidak ada lagi upload manual, tidak ada lagi "lupa deploy". Server Anda selalu mencerminkan kode terkini yang lulus test.

Workflow Deploy

Konsepnya: buat pasangan kunci SSH khusus deploy, taruh kunci publiknya di server (VPS), simpan kunci privatnya sebagai Secret di GitHub. Saat workflow berjalan, ia memakai kunci privat itu untuk masuk ke server dan menjalankan perintah pembaruan.

Langkah 1 — Siapkan kunci deploy

Salin# di komputer Anda: buat pasangan kunci khusus deploy (tanpa passphrase
# agar bisa dipakai otomatis oleh CI)
ssh-keygen -t ed25519 -C "deploy-actions" -f ./deploy_key -N ""

# deploy_key      -> kunci PRIVAT  (masuk ke GitHub Secrets)
# deploy_key.pub  -> kunci PUBLIK  (masuk ke server)

# tambahkan kunci publik ke server (VPS)
ssh-copy-id -i ./deploy_key.pub deploy@server-anda.com
# atau tempel manual isinya ke ~/.ssh/authorized_keys di server

Langkah 2 — Simpan Secrets di GitHub

Di Settings → Secrets and variables → Actions, buat tiga secret: SSH_PRIVATE_KEY (isi file deploy_key), SSH_HOST (IP/domain server), dan SSH_USER (nama user di server, mis. deploy).

Langkah 3 — Workflow deploy

Salin# .github/workflows/deploy.yml
name: Deploy
on: { push: { branches: [main] } }
jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      # pasang kunci privat dari Secret ke agent SSH runner
      - name: Setup SSH
        run: |
          mkdir -p ~/.ssh
          echo "${{ secrets.SSH_PRIVATE_KEY }}" > ~/.ssh/id_ed25519
          chmod 600 ~/.ssh/id_ed25519
          ssh-keyscan -H ${{ secrets.SSH_HOST }} >> ~/.ssh/known_hosts

      # masuk ke server & jalankan pembaruan
      - name: Deploy ke VPS
        run: |
          ssh ${{ secrets.SSH_USER }}@${{ secrets.SSH_HOST }} '
            cd /var/www/app &&
            git pull origin main &&
            npm ci --omit=dev &&
            npm run build &&
            pm2 restart app
          '

Ada juga action komunitas populer yang membungkus langkah SSH ini agar lebih ringkas. Prinsipnya sama; pastikan Anda memakai action tepercaya dan menyematkan versinya. Untuk aplikasi berbasis kontainer, pola serupa berlaku: SSH ke server lalu docker compose pull && docker compose up -d.

Automate the boring stuff, so humans can do the interesting stuff.

Filosofi umum DevOps

Semua yang Anda bangun rapuh tanpa keamanan. Satu token bocor, satu dependensi rentan, atau satu akun tanpa 2FA bisa meruntuhkan reputasi bertahun-tahun. Kabar baiknya: GitHub menyediakan lapisan pertahanan gratis yang, jika diaktifkan, menutup sebagian besar celah umum.

Dependabot & Secrets

Dependabot memantau dependensi proyek Anda dan otomatis membuka PR saat ada versi yang menambal kerentanan keamanan. Aktifkan di Settings → Code security. Ia juga bisa rutin memperbarui dependensi biasa. Anda tinggal meninjau dan merge.

Salin# .github/dependabot.yml — cek update npm tiap minggu
version: 2
updates:
  - package-ecosystem: "npm"
    directory: "/"
    schedule: { interval: "weekly" }
  - package-ecosystem: "github-actions"
    directory: "/"
    schedule: { interval: "weekly" }

Secret scanning & push protection

GitHub bisa memindai apakah ada token/kunci yang tak sengaja ter-commit dan bahkan memblokir push yang mengandung rahasia (push protection). Aktifkan keduanya. Jika sebuah rahasia terlanjur bocor, jangan hanya menghapusnya dari kode — cabut (revoke) dan ganti segera, karena ia sudah ada di riwayat.

Branch Protection, 2FA & Signed Commits

Branch protection (kini juga lewat "rulesets") melindungi main dari perubahan sembrono. Aturan umum yang layak diaktifkan:

• Wajib lewat Pull Request — tidak ada push langsung ke main.
• Wajib CI hijau sebelum merge (status checks required).
• Wajib minimal satu review yang menyetujui.
• Larang force-push dan penghapusan branch.
• Wajib branch up-to-date dengan main sebelum merge.

2FA — pertahanan akun terpenting

Aktifkan autentikasi dua faktor (2FA) di akun Anda hari ini juga. Ini mencegah pengambilalihan akun meski sandi Anda bocor. Gunakan aplikasi authenticator atau kunci keamanan fisik; simpan kode pemulihan di tempat aman. GitHub kini mewajibkan 2FA untuk banyak kontributor.

Signed commits — membuktikan penulis

Commit bisa "ditandatangani" secara kriptografis (GPG, SSH, atau S/MIME) sehingga GitHub menampilkan lencana Verified. Ini membuktikan commit benar-benar dari Anda, bukan seseorang yang memalsukan nama & email di config Git.

Salin# tandatangani commit memakai kunci SSH yang sudah Anda punya
git config --global gpg.format ssh
git config --global user.signingkey ~/.ssh/id_ed25519.pub
git config --global commit.gpgsign true
# lalu daftarkan kunci itu sebagai "Signing Key" di Settings GitHub

Trust, but verify.

Pepatah, populer di keamanan siber

Di 2026, pembaca repositori Anda bukan hanya manusia. Asisten AI membaca kode untuk membantu debugging, membuat ringkasan, dan menjawab pertanyaan tentang proyek. Repositori yang terstruktur baik tidak hanya ramah manusia — ia juga jauh lebih mudah dipahami mesin. Bab ini menjelaskan cara membuat repo Anda "terbaca AI".

Kenapa keterbacaan AI penting

Ketika Anda (atau kolaborator) meminta AI "jelaskan cara kerja proyek ini" atau "kenapa fungsi ini error", AI mengandalkan konteks yang tersedia: README, struktur folder, nama file, komentar, dan pesan commit. Semakin jelas sinyal-sinyal itu, semakin akurat bantuan yang Anda dapat. Repo yang berantakan menghasilkan jawaban AI yang menebak-nebak.

Praktik yang membuat repo ramah AI

• README sebagai peta. Jelaskan tujuan proyek, tumpukan teknologi, struktur folder, dan cara menjalankan di bagian atas. Ini konteks pertama yang dibaca AI.
• Nama yang deskriptif. hitungPajakTahunan() memberi tahu AI (dan manusia) apa yang terjadi; calc2() tidak.
• Struktur konsisten & dapat ditebak. src/, tests/, docs/ — pola standar membantu AI menavigasi tanpa menebak.
• Pesan commit yang bermakna. Riwayat yang jelas membantu AI menjelaskan kenapa sesuatu berubah, bukan hanya apa.
• Komentar untuk "kenapa", bukan "apa". Kode menjelaskan apa; komentar menjelaskan alasan & keputusan yang tak terlihat dari kode.
• Contoh nyata. Blok "Pemakaian" dengan input/output konkret memberi AI pola yang bisa ditiru.
• Dokumentasi mesin. File seperti openapi.yaml, tipe TypeScript, atau skema JSON adalah kontrak eksplisit yang dipahami AI dengan presisi.

File konteks khusus

Banyak tim kini menambahkan berkas panduan agar asisten AI memahami konvensi proyek: aturan gaya, perintah build/test, dan hal yang harus dihindari. Nama dan format berkas semacam ini masih berkembang antar-alat, tetapi idenya seragam — beri AI ringkasan konvensi proyek di satu tempat yang mudah ditemukan.

Salin# Contoh isi berkas panduan konteks proyek

## Ringkasan
API katalog produk. Node.js 20 + Express + PostgreSQL.

## Perintah penting
- Install: `npm ci`
- Test: `npm test`
- Jalankan dev: `npm run dev`

## Konvensi
- Gaya commit: Conventional Commits (feat/fix/docs/...)
- Semua endpoint di src/routes, logika di src/services
- Jangan pernah commit file .env

## Hindari
- Menambah dependensi berat tanpa diskusi
- Menulis logika bisnis di dalam route handler

Programs must be written for people to read, and only incidentally for machines to execute.

Harold Abelson, "SICP"

Anda telah menempuh perjalanan penuh: dari commit pertama sampai deploy otomatis ke server. GitHub kini bukan lagi kotak misteri, melainkan perkakas yang bekerja untuk Anda — mencatat, menguji, membangun, dan mengirim. Yang tersisa hanyalah kebiasaan: gunakan setiap hari, sedikit demi sedikit, dan biarkan profil Anda bertumbuh menjadi bukti yang tak terbantahkan.

Jangan menunggu proyek "cukup bagus" untuk dipublikasikan. Repositori terbaik adalah yang ada. Mulai dari kecil, perbaiki sambil jalan, dan biarkan dunia menyaksikan Anda belajar. Itulah semangat sejati open source.

The best time to plant a tree was 20 years ago. The second best time is now.

Pepatah, sering dikutip untuk memulai

FAQ — Pertanyaan yang Sering Muncul

1. Apakah GitHub gratis untuk selamanya?

Ya, tier gratis mencakup repo publik & privat tanpa batas, Actions dengan kuota menit, dan Pages. Fitur tim lanjutan dan kuota lebih besar berbayar. verifikasi ke dokumentasi resmi GitHub

2. GitHub dan Git itu sama?

Tidak. Git adalah sistem kontrol versi (perangkat lunak di komputer Anda). GitHub adalah layanan online yang menghosting repo Git dan menambahkan kolaborasi, otomasi, serta hosting.

3. Repo saya harus public atau private?

Untuk portofolio: public (agar terlihat). Untuk kode klien/rahasia: private. Anda bisa punya keduanya sesuai kebutuhan tiap proyek.

4. Bagaimana kalau saya salah push sesuatu yang rahasia?

Segera cabut/ganti rahasia itu di penyedianya (anggap sudah bocor), lalu bersihkan dari riwayat. Menghapus commit saja tidak cukup. Aktifkan push protection agar tak terulang.

5. Apa itu fork vs clone?

Clone menyalin repo ke komputer Anda. Fork membuat salinan repo orang lain ke akun GitHub Anda — biasanya langkah awal berkontribusi ke proyek yang tidak Anda miliki.

6. Kenapa contribution graph saya kosong padahal saya commit?

Pastikan email di config Git Anda cocok dengan email terverifikasi di akun GitHub. Commit dengan email lain tidak dihitung. Untuk repo privat, aktifkan tampilan kontribusi privat di pengaturan profil.

7. Apa bedanya merge, squash, dan rebase?

Merge menyimpan seluruh riwayat cabang. Squash menggabung semua commit PR jadi satu (main jadi rapi). Rebase menempel commit tanpa merge commit. Untuk portofolio, squash paling bersih.

8. Actions saya gagal terus, bagaimana debug?

Buka tab Actions, klik run yang gagal, lalu klik step merah untuk melihat log. Baca pesan error dari bawah ke atas. Sering kali penyebabnya: dependensi hilang, versi Node beda, atau perintah yang tidak ada di lingkungan CI.

9. Apakah saya perlu tahu semua perintah Git?

Tidak. Sepuluh perintah di Bab 2 menutupi hampir semua pekerjaan harian. Sisanya dipelajari saat dibutuhkan.

10. SSH atau HTTPS untuk mengakses repo?

Keduanya aman. SSH lebih nyaman untuk mesin pribadi jangka panjang (tanpa ketik sandi). HTTPS + token cocok untuk skrip/lingkungan sementara.

11. Berapa banyak repo yang ideal di profil?

Tidak ada angka pasti. Lebih penting kualitas: beberapa repo rapi dengan README bagus mengalahkan puluhan repo kosong. Pin enam terbaik Anda.

12. Bisakah saya deploy aplikasi backend (Node/Python) ke GitHub Pages?

Tidak — Pages hanya untuk situs statis. Untuk backend, deploy ke VPS/PaaS (Bab 13) atau layanan hosting aplikasi.

13. Apa itu GitHub Actions "menit" yang katanya terbatas?

Setiap workflow memakai waktu komputasi (menit) di server GitHub. Tier gratis punya kuota bulanan; repo publik umumnya jauh lebih murah/gratis dibanding privat. verifikasi ke dokumentasi resmi GitHub

14. Bagaimana cara berkontribusi ke proyek open source?

Fork repo → buat branch → perbaiki/tambah → push ke fork Anda → buka Pull Request ke repo asli. Baca file CONTRIBUTING.md proyek dulu, dan mulai dari issue berlabel "good first issue".

15. Apakah aman menaruh deploy key privat di GitHub Secrets?

Ya — Secrets terenkripsi dan tak terlihat di log. Risikonya ada pada action pihak ketiga yang jahat; pin versi & pakai action tepercaya. Gunakan kunci deploy terbatas (bukan kunci pribadi utama Anda), dan user server non-root.

16. Apa itu monorepo?

Satu repositori berisi banyak proyek/paket sekaligus (mis. frontend + backend + library bersama). Cocok untuk tim yang ingin versi & CI terpadu, dengan tooling seperti workspaces.

Glosarium

Checklist Repo Profesional

Sebelum menganggap sebuah repo "siap dipamerkan", pastikan hal-hal ini terpenuhi:

• Nama repo deskriptif (huruf kecil, tanda hubung).
• Description & topics terisi.
• README lengkap: judul, badge, fitur, instalasi, pemakaian, lisensi.
• File LICENSE ada dan sesuai niat Anda.
• .gitignore menutup file sampah & rahasia.
• Tidak ada rahasia/token di kode maupun riwayat.
• Struktur folder rapi (src/, tests/, docs/).
• Workflow CI berjalan & badge status hijau di README.
• Test ada dan lulus di CI.
• Branch main dilindungi (PR + CI wajib).
• 2FA aktif di akun Anda.
• Commit terakhir bermakna, bukan "asdf" atau "update".
• Repo bisa dipahami AI hanya dari README + struktur.

Terima kasih telah membaca. Sekarang buka terminal Anda, dan bangun sesuatu yang bisa dilihat dunia. Selamat berkarya.

Lampiran — Lembar Contekan

Simpan halaman ini. Ia merangkum perintah dan pola yang paling sering Anda butuhkan sehari-hari, dari Git dasar sampai deploy.

Git harian

GitHub CLI (gh)

Pola workflow yang sering dipakai

Simplicity is prerequisite for reliability.

Edsger W. Dijkstra