Masalah Tanpa Version Control

Budi Santoso sedang menyusun laporan mingguan untuk kantornya. Laporan itu disunting hampir setiap hari: atasan meminta perubahan, Siti mengirim koreksi lewat surel, dan Budi sendiri menambal kesalahan ketikan menjelang tengah malam. Semua pengelolaan versi dilakukan dengan cara paling umum di dunia: menyimpan salinan berkas dengan nama berbeda. Dua minggu kemudian, folder kerjanya berisi beranak-pinakan berkas yang saling mirip dan tidak seorang pun berani memastikan berkas mana yang benar-benar terakhir. Chapter ini membedah skenario seperti itu secara konkrit supaya manfaat version control terasa nyata, bukan sekadar teori.

Skenario Laporan yang Berceceran #

Mari kita lihat isi folder kerja Budi setelah dua minggu mengelola revisi secara manual:

laporan-final-v2-revisi-FIX-budi.txt
laporan-final-v2-revisi-FIX.txt
laporan-final-v2-revisi.txt
laporan-final-v2.txt
laporan-final.txt
laporan.txt

Enam berkas di atas adalah enam keputusan penyimpanan manual. Setiap kali Budi ingin “menyimpan” sebuah versi, satu salinan baru dibuat dengan nama yang sedikit berbeda. Awalnya nama masih pendek, lalu memanjang menjadi laporan-final-v2-revisi-FIX-budi.txt — dan justru nama terpanjang itulah yang paling tidak bisa dipercaya: kata final sudah dipakai dua kali sebelumnya, dan akhiran budi hanya menandakan dari komputer mana salinan itu berasal, bukan isinya yang mana yang benar.

Alur penyimpanan manual tersebut berbentuk seperti ini:

Diagram memperlihatkan akar masalahnya: satu berkas beranak menjadi banyak salinan tanpa penanda hubungan antarversi. Ketika Siti meminta “kirim versi terakhir yang sudah diperbaiki”, Budi harus menebak berkas mana yang dimaksud, dan menebak salah berarti mengirim revisi yang salah.

Masalah yang Berulang #

Pola seperti ini bukan cerita fiksi semata: pembuka buku Pro Git bahkan membayangkan desainer yang ingin menyimpan setiap versi gambar atau tata letaknya — persis dilema Budi. Pola pada skenario Budi muncul di hampir semua pekerjaan yang tidak memakai version control, dan empat masalah berikut adalah yang paling sering terjadi.

Versi Terbaru Tidak Pasti #

Nama berkas tidak sanggup merekam kronologi. Tidak ada yang memastikan laporan-final-v2-revisi-FIX.txt lebih baru daripada salinan dari laptop kantor, karena keduanya bisa saja disunting pada waktu berbeda di tempat berbeda. Versi “terbaru” akhirnya ditentukan oleh ingatan, dan ingatan bisa keliru.

Suntingan Saling Menimpa #

Ketika Budi dan Siti menyunting berkas yang sama dari folder bersama, siapa pun yang menyimpan terakhir akan menimpa hasil kerja orang sebelumnya. Perubahan yang tertimpa hilang tanpa jejak — tidak ada peringatan, tidak ada salinan cadangan, dan tidak ada cara menggabungkan keduanya.

Tidak Bisa Kembali ke Versi Lama #

Paragraf yang dihapus kemarin ternyata masih dibutuhkan hari ini. Tanpa riwayat, satu-satunya cara “kembali” adalah mengingat isi paragraf itu lalu mengetik ulang. Semakin jauh ke masa lalu, semakin mustahil pemulihannya dilakukan.

Tidak Tahu Siapa Mengubah Apa #

Enam salinan tidak menyimpan informasi siapa penyuntingnya dan kapan disimpan. Ketika muncul angka yang salah di bagian keuangan, tidak ada cara memastikan perubahan itu masuk lewat revisi atasan, koreksi Siti, atau tambal-tambal tengah malam Budi.

Apa yang Diberikan Version Control #

Setiap masalah di atas punya pasangan solusi pada sistem version control. Tabel berikut memetakan keduanya secara langsung:

Perhatikan pola pada kolom kanan: version control tidak sekadar menyimpan salinan, melainkan menyimpan hubungan antarversi — siapa menyimpan, kapan, apa bedanya dengan versi sebelumnya, dan mengapa disimpan. Enam masalah di kolom kiri hilang bukan karena salinannya lebih banyak, tetapi karena strukturnya lebih rapi.

Masalah-masalah Budi sudah jelas, dan kategori solusinya pun sudah kita kenal pada chapter sebelumnya. Langkah berikutnya adalah mengenal alat yang dipakai mayoritas dunia pemrograman untuk menyelesaikannya: Git — materi chapter Mengenal Git .