Belajar Git - Sejarah, Latar Belakang & Mengapa Membutuhkan VCS

#Pendahuluan

Di episode 0 kita menyiapkan lingkungan: terminal, Git 2.4x, akun GitHub, dan autentikasi SSH. Sekarang waktunya menjawab pertanyaan paling mendasar: kenapa kita butuh Git sama sekali?

Sebelum memahami cara kerja Git, kita harus memahami masalah yang dipecahkannya. Version Control System (VCS) lahir dari rasa sakit yang sangat nyata: kehilangan pekerjaan, kode tim yang saling menimpa, dan ketidakmampuan menjawab pertanyaan sederhana seperti "siapa yang mengubah baris ini dan kenapa?". Episode ini mengajak kalian memahami perjalanan dari kekacauan menuju sistem yang kita pakai hari ini.

#Masalah Manajemen Kode Tanpa VCS

#Kegagalan Versi Manual

Bayangkan pola ini — pola yang sangat familiar di awal karier setiap developer:

ls ~/projects
project_v1.zip
project_v1_fixed.zip
project_v2.zip
project_final.zip
project_final_beneran.zip
project_final_beneran2_FINAL.zip

Lihat masalahnya: nama file ambigu, tidak ada catatan perubahan, dan tidak ada yang tahu apa isi atau kapan project_final_beneran2_FINAL.zip dibuat. Versi tidak terdokumentasi berarti versi tidak bisa diandalkan. Setelah beberapa bulan, arsip seperti ini hanya sampah digital.

#Kesulitan Kolaborasi

Tanpa VCS, dua developer yang mengedit file sama akan saling menimpa pekerjaan. Satu-satunya cara menghindarinya adalah komunikasi manual yang rapuh ("kamu edit dulu, nanti aku lanjut"). Tidak ada jejak siapa mengubah apa, bug masuk tanpa diketahui kapan, dan solusi manual ini selalu gagal begitu timnya membesar.

#Evolusi Version Control System

#Centralized VCS

Generasi pertama VCS — Subversion (SVN), Perforce — memusatkan seluruh riwayat di satu server. Developer melakukan checkout ke mesin lokal, mengerjakan, lalu commit kembali ke server.

Keunggulannya: satu sumber kebenaran dan kontrol akses terpusat. Namun kelemahannya fatal:

• Single point of failure — server mati berarti seluruh riwayat proyek lenyap.
• Tergantung jaringan — semua operasi butuh koneksi; offline berarti berhenti bekerja.
• Sulit branching — membuat cabang di server mahal dan rawan konflik.

#Distributed VCS

Git dan Mercurial membalik paradigma ini: setiap developer memiliki salinan penuh repository — seluruh sejarah, seluruh branch, seluruh data — di mesin lokalnya.

git clone https://github.com/akun/proyek.git

Perhatikan: git clone bukan "download file terbaru", melainkan menyalin seluruh database repository. Konsekuensinya besar — lihat keunggulan berikut.

#Keunggulan Distributed VCS

• Bekerja offline — commit, log, diff, dan branch semuanya lokal; koneksi hanya dibutuhkan saat push dan pull.
• Cepat — hampir semua operasi berjalan di mesin lokal tanpa latensi jaringan.
• Full history lokal — seluruh riwayat ada di setiap mesin; server bukan satu-satunya penyimpanan.
• Resilient — jika server utama hilang, salinan lokal mana pun bisa menjadi pengganti.

Ini pergeseran filosofis: dari "server adalah sumber kebenaran" menjadi "setiap developer memiliki sumber kebenaran, dan mereka saling menyinkronkan".

#Sejarah Singkat Git: Lahir dari Krisis

Tahun 2005, para pengembang kernel Linux menghadapi masalah: mereka memakai BitKeeper, DVCS proprietary yang menarik lisensi gratisnya. Linus Torvalds tidak mau kembali ke centralized VCS yang menghambat kolaborasi ribuan kontributor. Maka, dalam hitungan minggu, ia membangun Git.

Kriteria yang ia tetapkan sejak awal:

• Kecepatan — patch kernel berjumlah ribuan per hari; Git harus secepat mungkin.
• Desain sederhana — model data minimal, mudah dipahami dan dipertahankan.
• Dukungan penuh branching non-linear — ribuan kontributor bekerja paralel.
• Integritas data — setiap objek diidentifikasi dengan cryptographic hash sehingga data tidak bisa berubah diam-diam tanpa terdeteksi.

git log --oneline
a1b2c3d feat: tambah modul autentikasi
e4f5g6h fix: perbaiki null pointer di login
a7b8c9d Initial commit

Di sini terlihat kekuatan Git: setiap perubahan tercatat rapi, dengan hash unik dan pesan yang menjelaskan tujuannya. Detail lebih dalam akan kita bedah di episode 4.

#Filosofi Dasar Git

Empat filosofi ini bukan sekadar slogan — semuanya akan kalian temui langsung di episode-episode berikutnya.

#Kecepatan (Speed)

Hampir semua operasi Git berjalan lokal tanpa komunikasi jaringan. git log, git diff, dan git branch terasa instan bahkan di repository raksasa sekalipun.

#Desain Sederhana (Simple Design)

Git tidak menyimpan "perubahan" seperti kebanyakan VCS lain, melainkan snapshot dari kondisi seluruh file pada tiap commit. Model data yang sederhana ini justru membuat operasi seperti merge dan diff menjadi andal.

#Branching Non-Linear

Branch di Git sangat murah — hanya sebuah pointer ringan. Alur kerja seperti "fitur dikerjakan di branch terpisah lalu di-merge" menjadi praktik harian, bukan pengecualian yang ditakuti.

#Integritas Melalui Cryptographic Hashing

Setiap objek Git di-hash dengan SHA-1 (dan kini mulai beralih ke SHA-256). Perubahan satu bit pada file mana pun akan mengubah hash-nya dan langsung terdeteksi oleh Git.

#Penutup

Inilah inti dari episode 1:

• Tanpa VCS, versi manual dan kolaborasi rawan bencana.
• VCS centralized (SVN, Perforce) punya satu titik kegagalan dan bergantung jaringan.
• VCS distributed (Git, Mercurial) memberi setiap developer full repository lokal.
• Git lahir tahun 2005 dari kebutuhan kernel Linux, dibangun oleh Linus Torvalds.
• Filosofinya: kecepatan, desain sederhana, branching non-linear, dan integritas data.

Di episode 2 berikutnya kita membedah bagian paling menarik: arsitektur internal Git — tiga area (working directory, staging area, repository), model snapshot, dan objek-objek seperti blob, tree, dan commit. Di sana kalian akan melihat kenapa desain Git begitu elegan. Sampai jumpa!