Skala, Pemulihan
& Rangkuman
Chapter penutup: kemampuan yang membedakan orang yang panik saat repo kacau dari orang yang tahu di mana commit “hilang” disimpan, lalu satu rangkuman yang menyatukan seluruh course jadi keputusan praktis.
Enam chapter sebelumnya membangun alur dari fondasi sampai workflow tim. Chapter penutup ini melengkapi dua hal terakhir: skala dan pemulihan, bagaimana repo besar dikelola dan bagaimana memulihkan saat sesuatu terlihat lenyap, lalu rangkuman yang menjahit semua benang course menjadi satu model mental dan satu rekomendasi praktis per ukuran tim. Kabar baiknya, Git jarang benar-benar membuang data, ia hanya menyembunyikannya sampai kamu tahu cara melihatnya.
Topik Lanjutan dan Troubleshooting
Monorepo, submodule, bisect, pitfalls, security, CI/CD
Kumpulan kemampuan yang membedakan orang yang panik saat repo kacau dari orang yang tahu di mana commit “hilang” disimpan.
Setelah alur dasar lancar, sisa perjalanan adalah skala dan pemulihan, bagaimana repo besar dikelola, bagaimana melacak bug ke commit penyebabnya, dan apa yang dilakukan saat sesuatu terlihat lenyap. Kabar baiknya, Git jarang benar-benar membuang data, ia hanya menyembunyikannya sampai kamu tahu cara melihatnya.
Skala: monorepo, submodule, subtree
Monorepo menampung banyak layanan dalam satu repo. Kuncinya kepemilikan path lewat CODEOWNERS (yang sudah kamu pasang di Chapter 4), agar PR di area tertentu otomatis meminta review pemilik area. Submodule dan subtree menyematkan repo lain, submodule menyimpan pointer ke commit eksternal, tapi keduanya menambah kompleksitas nyata dan sering lebih baik dihindari kecuali ada kebutuhan kuat. Apa pun pilihannya, PR kecil tetap aturan emas.
Untuk repo yang benar-benar raksasa, Git modern punya beberapa fitur performa yang layak dikenal:
sparse-checkout (cone mode)
Hanya meng-checkout sebagian direktori ke disk, sehingga git status dan git add tak perlu memindai file yang tak kamu kerjakan.
partial clone
git clone —filter=blob:none membuat blobless clone: semua commit dan tree ikut, isi file diunduh saat dibutuhkan. Riwayat tetap utuh, clone jauh lebih ringan.
scalar
Mengaktifkan sparse-checkout dan background maintenance secara default untuk enlistment besar, “membungkus” praktik terbaik repo raksasa jadi satu perintah.
git maintenance
Menjalankan optimasi (repack, commit-graph, prefetch) di latar belakang agar perintah harian tetap cepat seiring repo membesar.
Di monorepo besar, sparse-checkout cone mode dipasangkan dengan sparse index dan filesystem monitor membuat operasi harian terasa seperti repo kecil: Git tak lagi menyusuri seluruh pohon kerja, hanya bagian yang relevan dengan tugasmu.
git bisect: berburu commit penyebab bug
Saat sebuah bug muncul entah kapan, jangan menebak. git bisect melakukan pencarian biner di antara commit yang masih baik dan yang sudah rusak, membelah rentang sampai menemukan commit pertama yang merusak.
Terminalgit bisect start git bisect bad # commit sekarang rusak git bisect good v1.0.0 # versi ini masih sehat # Git checkout commit di tengah, kamu uji, lalu beri tahu hasilnya: git bisect good # atau: git bisect bad # ulangi sampai Git menunjuk "first bad commit" git bisect reset # kembali ke posisi semula
Bisect. 1000 commit ditelusuri hanya dalam ~10 langkah karena tiap jawaban memotong setengah ruang pencarian.
Pitfalls dan pemulihan lewat reflog
Jebakan tersering, detached HEAD, stale branch yang tertinggal jauh, commit nyasar di branch salah, dan force push yang menimpa kerja orang. Penyelamatnya satu, git reflog, catatan setiap pergerakan HEAD di mesinmu. Bahkan setelah reset --hard yang kamu pelajari di Chapter 5, commit lama masih tercatat di reflog dan bisa dipulihkan.
Terminalgit reflog # contoh: a1b2c3d HEAD@{2}: commit: add cart git switch -c rescue a1b2c3d # tahan commit "hilang" dengan branch baru
Detached HEAD berarti commit yang tidak dipegang branch mana pun, mudah ter-garbage-collect. Selalu git switch -c <branch> sebelum commit dalam keadaan ini. Dan force push hanya boleh ke branch milikmu sendiri, gunakan —force-with-lease agar batal bila ada commit orang lain yang belum kamu lihat.
Security dan CI/CD sebagai gerbang
Hygiene minimal, pastikan .env tidak pernah masuk repo, aktifkan secret scanning untuk menangkap kunci yang bocor, pertimbangkan signed commit untuk membuktikan author, dan terapkan least privilege pada akses. Bila secret pernah ter-commit, rotasi (ganti) kuncinya, menghapus dari history saja tidak cukup karena clone lama tetap menyimpannya. CI/CD mengikat semua ini, required status check menjadikan lolosnya test sebagai syarat merge (gerbang), sementara deploy bisa branch-based (merge ke main memicu staging) atau tag-based (tag v* memicu rilis produksi).
Mendebug error runtime, kamu mempersempit ke baris kode penyebab. Mendebug repo sama persis, bisect mempersempit ke commit penyebab, dan reflog adalah stack trace pergerakan HEAD-mu.
Latih pemulihan nyata, pakai git bisect untuk melacak satu regression, lalu pindahkan sebuah commit yang nyasar di branch salah dan pulihkan hasil reset —hard yang tak sengaja lewat git reflog.
Ringkasan dan Workflow Rekomendasi
Dari kerja sendiri ke tim yang aman dan scalable
Git yang kamu kuasai sekarang bukan kumpulan perintah, melainkan satu model mental yang konsisten dari snapshot sampai kolaborasi tim.
Mari satukan benang seluruh course. Semua dimulai dari satu ide di Chapter 1, Git menyimpan snapshot, bukan diff, dengan tiga area yang menjelaskan kenapa add dan commit terpisah. Chapter 2 membangun loop harian: commit atomik dengan pesan yang menjelaskan “kenapa”, dibaca kembali lewat history. Chapter 3 membuka kerja paralel lewat branch dan merge, plus conflict yang kamu selesaikan dengan tenang. Chapter 4 membawa semuanya ke tim lewat remote, Pull Request, dan branch protection. Chapter 5 memberi kendali membedah sejarah dengan rebase dan undo yang aman. Chapter 6 menatanya jadi konvensi dan workflow. Dan chapter ini menutup dengan skala dan pemulihan. Workflow tim hanyalah cara menata semua itu untuk banyak orang.
Yang Wajib Menempel
- Git menyimpan snapshot, bukan diff, hash menjamin integritas tiap versi.
- Tiga area (working tree, index, repo) menjelaskan kenapa staging ada dan berguna.
- Commit yang baik bersifat atomik dengan pesan yang menjelaskan “kenapa”.
- Branch itu murah, merge menyatukan, fast-forward bila linear, merge commit bila bercabang.
- Conflict itu normal, selesaikan dengan memahami kedua sisi, bukan menghapus salah satunya.
- Remote, PR, dan review adalah tempat kualitas tim benar-benar terjaga.
- Branch protection dan required status check menjadikan standar tidak bisa dilewati.
- Rebase merapikan history (hanya yang belum dibagikan), revert aman untuk history publik.
- reflog adalah jaring pengaman, commit jarang benar-benar hilang.
Prinsip akhir yang menyatukan semuanya, mulai dari yang sederhana, tambah kompleksitas hanya saat tim dan deployment benar-benar membutuhkannya. Workflow yang berat sebelum waktunya adalah pajak harian tanpa imbalan.
Tim kecil / solo
GitHub Flow atau Trunk-Based. Satu main yang selalu siap deploy, branch pendek, PR ringan, CI dasar. Tidak perlu environment branch sampai deployment menuntutnya.
Tim sedang tumbuh
GitHub Flow plus branch protection, required review, dan CODEOWNERS. Tambah staging environment dan deploy branch-based saat rilis mulai perlu tahap.
Tim enterprise
GitLab Flow dengan environment branch atau Git Flow bila ada rilis berversi terjadwal. Rulesets ketat, signed commit, secret scanning, dan deploy tag-based ke produksi.
Langkah berikutnya bukan lagi membaca, melainkan berkolaborasi nyata, buka PR pertamamu di skincare-backend, minta review, dan biarkan CI menjadi gerbang. Saat alur itu terasa alami, kamu siap menyambungkannya ke pipeline CI/CD penuh, tempat setiap merge ke main mengantar kode dengan aman sampai ke pengguna.