Apa itu Git? Panduan Lengkap tentang Version Control

Apa Sebenarnya Git Itu

Git adalah sistem version control terdistribusi, yaitu sebuah software yang dirancang khusus untuk melacak perubahan pada sekumpulan file dari waktu ke waktu. Sistem ini memungkinkan banyak orang untuk berkolaborasi dalam proyek yang sama, mencatat riwayat lengkap dan terperinci mengenai perkembangan proyek tersebut, serta mengembalikan proyek ke kondisi sebelumnya kapan pun diperlukan. Meskipun pada prinsipnya Git dapat melacak perubahan pada jenis file apa pun, penggunaannya sebagian besar ditujukan untuk source code. Seluruh desainnya mencerminkan kebutuhan spesifik pengembangan software, yaitu melacak banyak perubahan teks kecil yang bersifat inkremental, sehingga mendukung banyak orang yang mengerjakan bagian-bagian proyek yang berbeda secara bersamaan, serta memungkinkan alur kerja terpisah dan paralel tersebut untuk akhirnya digabungkan kembali dengan benar.

Pada tingkat yang paling mendasar, tugas Git adalah menjawab serangkaian pertanyaan yang menjadi sangat sulit dijawab secara akurat ketika lebih dari satu orang mengerjakan codebase yang sama, atau ketika basecode tersebut telah ada cukup lama hingga memiliki riwayat yang signifikan, yaitu seperti Apa yang berubah sejak kemarin? Siapa yang melakukan perubahan spesifik ini, dan mengapa? Bisakah saya membatalkan perubahan tertentu ini dengan aman tanpa harus membatalkan semua hal lain yang terjadi setelahnya? Bisakah dua orang mengerjakan bagian yang benar-benar berbeda dari file yang sama—atau bahkan baris yang sama persis—dan kemudian hasil kerja mereka yang terpisah itu digabungkan dengan benar? Git menjawab setiap pertanyaan ini bukan melalui konvensi informal yang samar atau sekadar disiplin tim, melainkan melalui model data dasar yang presisi, terdefinisi dengan jelas, dan konsisten secara matematis—sebuah model yang dijelaskan secara rinci dalam bagian-bagian selanjutnya dari panduan ini.

Asal-usul Git

Git diciptakan pada tahun 2005 oleh Linus Torvalds—sosok yang juga menciptakan kernel Linux—dan latar belakang penciptaannya sangat layak untuk dipahami karena hal tersebut menjelaskan banyak hal mengenai alasan di balik desain Git yang khas itu.

Selama bertahun-tahun sebelum 2005, proyek kernel Linux—sebuah proyek open-source berskala masif dan tersebar secara global yang melibatkan ribuan kontributor—mengandalkan sistem version control berpemilik (proprietary) bernama BitKeeper. Sistem ini disediakan bagi komunitas Linux secara gratis melalui kesepakatan lisensi khusus dengan vendor komersialnya. Pada awal 2005, muncul perselisihan antara perusahaan penyedia BitKeeper dan salah satu anggota komunitas developer Linux terkait ketentuan kesepakatan tersebut; akibatnya, akses gratis BitKeeper untuk proyek ini dicabut sepenuhnya. Torvalds, yang membutuhkan pengganti yang benar-benar berfungsi dan siap pakai dalam waktu sangat singkat—serta dikenal tidak puas dengan alternatif sistem version control open source yang ada saat itu (ia menilainya—dengan gaya bicaranya yang blak-blakan—terlalu lambat dan secara fundamental tidak cocok dengan skala serta sifat pengembangan kernel Linux yang sangat terdistribusi dan memiliki koordinasi longgar)—memutuskan untuk menulis sendiri sistem version control yang benar-benar baru, mulai dari nol.

Pengembangan awal Git berlangsung sangat cepat dan luar biasa, di mana Torvalds mulai menulisnya pada awal April 2005, dan hanya dalam hitungan beberapa minggu, Git sudah digunakan untuk mengelola kode sumber kernel Linux itu sendiri, termasuk mengelola proses pengembangan lanjutannya yang terus berjalan. Kisah asal-usul ini secara langsung menjelaskan beberapa karakteristik desain Git yang paling khas, yaitu sistem ini dibangun khusus untuk menangani sejumlah besar kontributor yang bekerja dengan tingkat kemandirian dan otonomi yang tinggi satu sama lain; dibangun dengan prioritas utama dan tanpa kompromi pada kecepatan serta performa mentah (mengingat codebase kernel Linux—dan banyaknya perubahan individual yang terus-menerus diusulkan—sudah sangat masif bahkan pada tahun 2005); serta dibangun dengan model yang sangat terdistribusi, tanpa adanya keharusan teknis mendasar bagi server pusat atau otoritas tunggal mana pun untuk selalu tersedia secara terus-menerus.

Version Control Sebelum Git

Sistem version control awal, seperti CVS (Concurrent Versions System) dan kemudian Subversion (SVN), dibangun dengan model yang pada dasarnya terpusat. Dalam model ini, hanya terdapat satu salinan resmi dan otoritatif yang memuat seluruh riwayat proyek, yang disimpan di satu server pusat. Sementara itu, mesin lokal setiap developer hanya menyimpan salinan kerja parsial yang terbatas dari file-file proyek saat ini—bukan catatan riwayat lengkap proyek tersebut. Untuk melihat riwayat proyek, membuat branch baru, atau melakukan commit atas perubahan baru, software developer umumnya harus berkomunikasi langsung dengan server pusat tersebut melalui jaringan—pada dasarnya setiap kali tindakan tersebut dilakukan.

Model terpusat ini menciptakan beberapa keterbatasan praktis yang nyata. Keterbatasan ini menjadi semakin jelas dan menyulitkan seiring dengan berkembangnya ukuran proyek dan bertambahnya jumlah orang yang berkolaborasi di dalamnya. Setiap operasi penting—bukan hanya saat berbagi pekerjaan dengan orang lain, tetapi bahkan untuk tindakan dasar seperti melakukan commit perubahan atau sekadar melihat riwayat proyek—umumnya memerlukan koneksi jaringan yang aktif dan berfungsi ke server pusat tersebut. Akibatnya, bekerja sepenuhnya secara offline sering kali sulit atau bahkan mustahil dilakukan. Server pusat tersebut menjadi titik kegagalan tunggal yang nyata: jika server itu mati, tidak dapat diakses, atau hilang, seluruh riwayat lengkap proyek bisa ikut hilang secara permanen dan fatal, kecuali jika terdapat cadangan terpisah dan independen di tempat lain. Selain itu, pembuatan branch baru—yaitu jalur pengembangan yang terpisah dan independen—sering kali menjadi operasi yang berat dan memakan banyak sumber daya pada sistem-sistem lama ini. Hal tersebut membuat developer enggan untuk membuat dan menggunakannya sesering atau sebebas yang seharusnya bisa mereka lakukan.

Model terdistribusi Git merupakan respons langsung dan terencana untuk mengatasi keterbatasan-keterbatasan spesifik yang telah dipahami dengan baik tersebut.

Apa Arti Sebenarnya dari "Terdistribusi"

Dalam model terdistribusi Git, setiap developer yang melakukan clone terhadap sebuah repositori akan menerima salinan lengkap dan independen dari seluruh riwayat proyek—sebagai konsekuensi langsung dan otomatis dari operasi clone tersebut. Salinan ini tidak hanya mencakup versi terbaru dari file-file proyek, tetapi juga setiap commit, setiap branch, dan seluruh riwayat proyek yang tercatat sejak commit pertama kali dibuat. Ini adalah perbedaan arsitektur yang sangat mendasar dibandingkan dengan model terpusat yang lebih lama, dan hal ini membawa sejumlah konsekuensi praktis yang signifikan serta muncul secara alami dari model tersebut.

Karena salinan lokal repositori kita sudah memuat riwayat lengkap proyek, sebagian besar operasi sehari-hari di Git—seperti melihat riwayat proyek, membandingkan dua versi file yang berbeda, membuat branch baru, atau melakukan commit atas perubahan baru—dapat dilakukan sepenuhnya secara lokal di komputer kita sendiri, tanpa memerlukan koneksi jaringan sama sekali. Hal ini membuat operasi-operasi tersebut jauh lebih cepat dalam praktiknya (karena tidak ada proses komunikasi bolak-balik melalui jaringan) dan memungkinkan pekerjaan dilakukan secara offline dengan produktif, sangat berbeda dengan sistem terpusat lama yang telah disebutkan sebelumnya.

Karena clone lokal milik setiap developer sudah memuat riwayat lengkap proyek, maka berdasarkan desain fundamental Git itu sendiri, tidak ada titik kegagalan tunggal yang melekat pada sistem tersebut: jika server spesifik yang menampung salinan "resmi" atau kanonis proyek (umumnya, meski tidak selalu, adalah GitHub) tiba-tiba lenyap sepenuhnya esok hari, riwayat lengkap proyek tersebut akan tetap ada dan utuh di komputer lokal setiap developer yang pernah mengkloning repositori tersebut.

Selain itu, karena pembuatan cabang (branching) dan penggabungan (merging) diperlakukan sebagai operasi inti yang cepat dan ringan dalam desain dasar Git—bukan sekadar fitur tambahan yang canggung dan memakan banyak sumber daya yang dipaksakan pada sistem yang awalnya dirancang untuk tujuan penggunaan lain—para developer benar-benar didorong oleh desain dasar dan ergonomi alat ini untuk membuat cabang baru secara bebas dan sering. Hal ini secara langsung memungkinkan penerapan alur kerja berbasis pull request, di mana pekerjaan yang terisolasi dan independen dapat dilakukan dengan aman di branch terpisah sebelum secara resmi diusulkan untuk diintegrasikan ke dalam jalur pengembangan utama proyek yang digunakan bersama.

Bagaimana Git Sebenarnya Menyimpan Kode Kita

Sebuah kesalahpahaman umum yang tersebar luas adalah anggapan bahwa Git bekerja terutama dengan menyimpan daftar inkremental (berkelanjutan) mengenai perbedaan spesifik (atau "delta") antara setiap versi file yang berurutan; cara kerja ini mirip dengan mekanisme internal banyak sistem version control lama. Faktanya, Git sama sekali tidak bekerja dengan cara demikian. Sebaliknya, setiap kali kita melakukan commit, Git mengambil apa yang secara konseptual merupakan snapshot lengkap dari setiap file dalam seluruh proyek kita pada saat itu, lalu menyimpannya.

Sekilas, hal ini mungkin terdengar sangat boros ruang penyimpanan—bukankah menyimpan salinan lengkap setiap file pada setiap commit akan memakan jauh lebih banyak ruang disk dibandingkan sekadar menyimpan perbedaan inkremental yang relatif kecil di antara versi-versi tersebut? Git menghindari potensi pemborosan ini melalui teknik optimasi dasar yang cerdas dan penting, yaitu jika suatu file tidak mengalami perubahan sama sekali antara satu commit dan commit berikutnya, Git tidak akan menyimpan salinan duplikat yang mubazir dari konten file tersebut untuk kedua kalinya. Git hanya menyimpan referensi efisien yang mengarah kembali ke versi file yang sama persis, yaitu yang sudah ada dan tersimpan sebelumnya. Selain itu, Git mengompresi objek-objek yang disimpannya dan—terutama saat diperintahkan secara eksplisit melalui operasi yang disebut "packing"—secara berkala mengonsolidasi penyimpanan internalnya lebih lanjut menggunakan kompresi delta yang sesungguhnya di antara versi-versi file yang serupa dan saling berkaitan erat. Hasilnya, dalam praktik nyata pada proyek-proyek pada umumnya, efisiensi penyimpanan Git ternyata jauh lebih baik daripada yang mungkin dibayangkan melalui model mental sederhana "salinan lengkap pada setiap commit".

Setiap objek yang disimpan secara internal oleh Git—baik itu berupa snapshot dari konten sebuah file, struktur direktori, maupun commit itu sendiri—diidentifikasi dan direferensikan menggunakan hash kriptografis yang unik (secara historis, Git menggunakan algoritma hashing SHA-1 yang dihitung langsung dari konten aktual objek tersebut). Inilah alasan mengapa setiap commit Git memiliki deretan panjang huruf dan angka yang khas—dan tampak acak—sebagai pengenal uniknya; deretan tersebut bukanlah label arbitrer yang diberikan secara berurutan, melainkan sebuah hash yang dihitung secara langsung dan sepenuhnya dari konten aktual commit itu sendiri. Salah satu konsekuensi langsung dan penting dari desain ini adalah jika satu karakter saja di dalam commit tersebut diubah atau mengalami kerusakan setelahnya, hash yang dihitung ulang oleh Git untuk commit yang telah berubah itu akan menjadi sangat berbeda; hal inilah yang memberikan jaminan integritas bawaan yang kuat pada riwayat yang disimpan Git terhadap segala bentuk manipulasi yang tidak disengaja maupun yang disengaja (berniat jahat) yang mungkin tidak terdeteksi.

Commit: Unit Dasar Git

Commit adalah unit perubahan dan riwayat yang tunggal, mendasar, dan bersifat atomik dalam Git. Setiap commit merekam snapshot lengkap dari seluruh file proyek pada momen tertentu (seperti yang dijelaskan secara rinci di bagian sebelumnya), disertai dengan metadata pendukung yang bermakna dan berguna, yaitu seperti penulis spesifik yang melakukan perubahan tersebut, tanggal dan waktu persis saat perubahan dibuat, pesan commit yang ditulis oleh penulis untuk menjelaskan—dengan kata-kata mereka sendiri—apa sebenarnya perubahan tersebut dan, idealnya, mengapa perubahan itu benar-benar diperlukan atau dibuat; serta—yang sangat krusial dan penting—sebuah referensi yang menunjuk langsung ke commit induk yang mendahului commit tersebut (atau, dalam kasus khusus merge commit, referensi ke lebih dari satu commit induk sekaligus, karena merge commit adalah titik di mana dua jalur pengembangan yang sebelumnya terpisah dan berbeda arah disatukan kembali secara formal).

Referensi yang menunjuk ke induk inilah yang memungkinkan keseluruhan riwayat Git dipahami dan divisualisasikan secara tepat dan koheren sebagai sebuah graf yang saling terhubung, bukan sekadar daftar sederhana yang datar dan tanpa pembedaan—setiap commit menunjuk ke belakang menuju commit spesifik (atau, sekali lagi, beberapa commit dalam kasus merge) yang mendahuluinya secara langsung. Dengan menelusuri rantai referensi induk yang saling terhubung ini hingga ke belakang, Git (dan juga kita sebagai developer yang menggunakannya) dapat merekonstruksi riwayat lengkap proyek serta memahami bagaimana proyek tersebut berkembang—langkah demi langkah—mulai dari commit pertama hingga kondisinya saat ini.

Perlu ditekankan bahwa commit dalam Git dirancang agar bersifat immutable (tidak dapat diubah)—begitu sebuah commit dibuat, konten dan hash pengenal uniknya tidak boleh berubah lagi di kemudian hari. Operasi yang sekilas tampak mengubah riwayat commit yang sudah ada (seperti "git commit --amend" atau fitur interactive rebase Git yang lebih canggih dan serbaguna) sebenarnya tidak mengubah konten commit yang sudah ada sama sekali; Sebaliknya, mereka membuat commit yang benar-benar baru dengan hash yang baru dihitung, lalu sekadar memindahkan penunjuk branch terkait agar merujuk ke commit baru tersebut—alih-alih ke commit lama—sehingga commit lama yang kini tak lagi memiliki referensi pun ditinggalkan, tanpa pernah benar-benar mengubah commit tersebut secara langsung di tempatnya.

Tiga Area: Working Directory, Staging Area, dan Repository

Working directory adalah kumpulan file nyata yang dapat kita lihat dan edit secara langsung pada sistem file komputer lokal kita, yaitu file-file yang kita buka di editor kode, modifikasi, dan simpan perubahannya, persis seperti saat kita mengelola file biasa lainnya di komputer kita. Staging area adalah area perantara yang berfungsi khusus untuk menampung kumpulan perubahan yang secara sengaja dan eksplisit ingin kita sertakan dalam commit berikutnya; yang penting untuk dipahami, area ini bisa memuat sebagian saja dari total perubahan kita saat ini, tanpa harus menyertakan seluruh perubahan yang telah kita lakukan di working directory. Repository (yang sering disingkat secara informal menjadi "repo") adalah tempat penyimpanan riwayat commit proyek kita yang bersifat permanen—yaitu urutan commit yang terus bertambah dan telah dicatat secara permanen oleh Git, di mana setiap commit mewakili snapshot spesifik yang telah dilakukan secara resmi dan sengaja pada waktu tertentu di masa lalu.

Alur kerja sehari-hari yang menghubungkan ketiga area ini adalah sebagai berikut: pertama, kita memodifikasi satu atau beberapa file di dalam working directory (menggunakan perintah "git add" untuk memindahkan perubahan spesifik yang kita pilih dari working directory ke staging area), lalu kita mencatat perubahan yang ada di staging area tersebut secara resmi dan permanen sebagai commit baru (menggunakan perintah "git commit", yang mengambil snapshot lengkap, permanen, dan tidak dapat diubah dari apa yang ada di staging area pada saat itu, serta menambahkannya ke dalam riwayat permanen repository).

Nilai nyata dan khusus dari tahap staging ini—dibandingkan dengan sekadar melakukan commit secara otomatis dan sekaligus terhadap semua perubahan yang ada di direktori kerja kita—adalah kemampuannya memberikan kendali yang nyata, terencana, dan mendetail atas apa saja yang sebenarnya disertakan dalam setiap commit. Sebagai contoh, jika kita sedang mengerjakan dua perubahan yang sepenuhnya terpisah dan tidak saling berkaitan secara logis dalam direktori kerja yang sama, staging area memungkinkan kita untuk secara cermat dan sengaja menyiapkan (stage) lalu melakukan commit secara terpisah hanya untuk perubahan pertama—benar-benar independen dari perubahan kedua. Hasilnya adalah dua commit yang bersih, koheren secara individual, dan terpisah secara logis, alih-alih terpaksa menggabungkan dua perubahan yang sama sekali tidak berkaitan tersebut menjadi satu commit tunggal yang tercampur aduk tanpa alasan jelas dan jauh kurang bermanfaat.

Branch: Apa Sebenarnya Mereka Itu

Secara teknis, branch (cabang) di Git adalah hal yang sangat sederhana—jauh lebih sederhana daripada bayangan awal kebanyakan pengguna baru Git. Sebuah branch hanyalah penunjuk (pointer) bernama yang dapat dipindahkan, yang mengarah ke satu commit spesifik tertentu.

Saat kita membuat branch baru, Git tidak menduplikasi atau menyalin seluruh file proyek kita ke tempat lain—berbeda dengan kesan intuitif yang mungkin muncul dari istilah "branch" bagi mereka yang belum memahami mekanisme dasarnya. Git hanya membuat satu penunjuk baru yang kecil—dengan nama pilihan kita—yang awalnya mengarah ke commit yang sedang ditunjuk oleh branch aktif kita pada saat itu juga. Inilah alasan mengapa pembuatan branch baru di Git merupakan operasi yang sangat cepat, ringan, dan hampir instan: pada dasarnya, tidak banyak pekerjaan yang harus dilakukan Git selain sekadar membuat penunjuk baru yang kecil dan ringan ini.

Saat kita kemudian membuat commit baru sementara branch tersebut sedang aktif, Git secara otomatis menggeser penunjuk branch itu ke depan, sehingga ia selalu mengarah ke commit terbaru pada jalur pengembangan tersebut. Karena setiap branch yang terpisah hanyalah penunjuk independen yang bisa digeser maju secara mandiri, dua branch yang berbeda dapat dengan mudah dan alami bercabang dari satu commit yang sama, lalu masing-masing mengakumulasi rangkaian commit lanjutan yang benar-benar berbeda dan independen, tanpa saling mengganggu atau memengaruhi satu sama lain.

Branch spesifik yang sedang kita "checkout"—artinya file-file di direktori kerja kita saat ini mencerminkan snapshot dari commit yang sedang ditunjuk oleh branch tersebut—dilacak secara internal oleh Git melalui penunjuk khusus yang secara konvensional disebut sebagai HEAD. Berpindah antar-branch (melalui perintah "git checkout" atau—pada versi Git yang lebih modern—perintah "git switch" yang lebih spesifik) hanya menggeser penunjuk HEAD ini agar mengarah ke branch lain. Selanjutnya, Git secara otomatis memperbarui file-file di direktori kerja kita agar sesuai dengan snapshot dari commit terkini pada branch yang baru dipilih tersebut.

Merging dan Cara Git Menggabungkan Perubahan

Setelah dua branch yang sepenuhnya terpisah masing-masing mengumpulkan riwayat commit baru yang independen, merging atau penggabungan adalah proses khusus untuk menyatukan kembali dua jalur pengembangan yang sebelumnya berbeda arah tersebut menjadi satu jalur tunggal yang utuh.

Saat kita menggabungkan satu branch ke branch lainnya, Git pertama-tama mengidentifikasi commit terbaru yang dimiliki bersama oleh kedua branch tersebut sebagai titik asal (ancestor) dalam riwayat masing-masing (yang disebut sebagai "merge base"). Kemudian, Git membandingkan seluruh perubahan yang terjadi pada masing-masing branch secara terpisah sejak titik temu tersebut. Jika kedua branch mengubah bagian file proyek yang sepenuhnya berbeda dan tidak tumpang tindih, Git biasanya dapat menggabungkan kedua rangkaian perubahan tersebut secara otomatis tanpa memerlukan intervensi atau panduan manusia. Hasilnya adalah commit baru (yang tepat disebut sebagai "merge commit") yang memiliki dua commit induk—berbeda dari commit biasa yang hanya memiliki satu induk—di mana masing-masing induk merujuk pada salah satu dari dua branch yang digabungkan tersebut.

Sebaliknya, jika kedua branch yang digabungkan sama-sama mengubah baris yang persis sama pada file yang sama dengan cara yang berbeda dan tidak kompatibel, Git tidak dapat menentukan secara otomatis versi mana yang harus dipertahankan atau bagaimana cara menggabungkannya dengan tepat. Situasi ini secara umum disebut sebagai merge conflict (konflik penggabungan). Ketika situasi ini terjadi, Git menghentikan proses penggabungan di tengah jalan dan secara eksplisit menandai lokasi konflik di dalam file yang bersangkutan. Selanjutnya, developer-lah yang bertanggung jawab untuk memeriksa bagian yang berkonflik tersebut, memutuskan secara manual versi mana yang benar (atau sering kali membuat kombinasi baru dari kedua versi yang berkonflik tersebut), serta menandai bahwa konflik telah diselesaikan dengan baik sebelum proses penggabungan secara keseluruhan dapat diselesaikan dengan sukses.

Penting untuk dipahami bahwa konflik penggabungan itu sendiri bukanlah tanda bahwa pasti ada sesuatu yang salah, ataupun indikasi adanya bug atau kekeliruan nyata; hal tersebut hanyalah konsekuensi yang wajar, dapat diperkirakan, dan tak terelakkan ketika lebih dari satu orang bekerja secara bersamaan pada bagian-bagian codebase yang saling terkait dan tumpang tindih. Git, sesuai dengan rancangannya, secara tepat menolak untuk menebak-nebak secara otomatis dan diam-diam mengenai bagaimana perubahan yang saling bertentangan tersebut seharusnya diselaraskan; sebaliknya, Git menyerahkan keputusan tersebut secara aman dan tepat kepada manusia yang memahami konteksnya.

Jadi, pada intinya, Git merupakan solusi yang sangat elegan dan koheren untuk masalah spesifik yang sudah dipahami dengan baik, yaitu melacak perubahan proyek dari waktu ke waktu sekaligus memungkinkan banyak orang untuk berkolaborasi secara efektif dan andal dalam proyek bersama tersebut. Arsitektur terdistribusinya—di mana mesin lokal setiap developer menyimpan salinan lengkap dan independen dari seluruh riwayat proyek—secara langsung mengatasi keterbatasan nyata (yang terdokumentasi dengan baik) dari sistem kontrol versi terpusat yang ada sebelumnya.