Evolusi Git untuk 10 Tahun Berikutnya

• Git, yang digunakan oleh para developer di seluruh dunia, sedang mendorong perubahan struktural untuk mempersiapkan 10 tahun ke depan, dengan perombakan utama berfokus pada keamanan, skalabilitas, dan kemudahan penggunaan
• Perubahan yang paling mencolok adalah transisi dari SHA-1 ke SHA-256; penggunaan SHA-1 dijadwalkan dilarang pada 2030, tetapi adopsinya tertunda karena kurangnya dukungan ekosistem
• Melalui adopsi Reftable, sedang dilakukan upaya untuk mengelola ratusan juta referensi secara efisien serta mengatasi keterbatasan filesystem dan masalah konkurensi
• Untuk meningkatkan penanganan file berukuran besar, Large-object promisors dan database objek pluggable sedang dikembangkan, dan diintegrasikan secara bertahap mulai versi setelah Git 2.50
• Dipengaruhi oleh sistem kontrol versi baru seperti Jujutsu, Git ingin mendukung workflow modern melalui penyederhanaan UI dan penambahan perintah baru

---

Mengapa Git perlu berubah

• Sejak dirilis pada 2005, Git telah menjadi alat inti yang diandalkan oleh jutaan repositori dan tak terhitung banyaknya skrip selama 20 tahun
  • Namun, perubahan lingkungan seperti kerentanan keamanan SHA-1, meningkatnya jumlah repositori besar, dan meluasnya pipeline CI mulai memperlihatkan keterbatasan strukturalnya
• Kemungkinan tabrakan SHA-1 telah terbukti melalui serangan SHAttered oleh CWI dan Google pada 2017
  • Dengan meningkatnya daya komputasi GPU, organisasi besar kini telah mencapai tingkat kemampuan untuk menghitung tabrakan hash
• Git memilih evolusi bertahap alih-alih redesain revolusioner, dan sedang mendorong perubahan sambil tetap menjaga kompatibilitas dengan ekosistem yang ada

Transisi ke SHA-256

• Dukungan SHA-256 ditambahkan di Git 2.29 (Oktober 2020), tetapi platform utama seperti GitHub masih belum mendukungnya
  • Git, Dulwich, dan Forgejo sudah mendukung penuh, sementara GitLab, go-git, dan libgit2 masih berada pada tahap dukungan eksperimental
• SHA-1 digunakan hanya untuk verifikasi integritas sederhana, tetapi seluruh ekosistem—termasuk tanda tangan, CI, dan skrip—beroperasi dengan asumsi adanya ketahanan terhadap tabrakan
• Regulasi pemerintah dan perusahaan menuntut penghapusan SHA-1 pada 2030, dan SHA-256 dijadwalkan menjadi default di Git 3.0
• Untuk membantu transisi ekosistem, pengguna dianjurkan berpartisipasi dengan menguji alat dan meminta dukungan forge

Adopsi Reftable

• Git saat ini menggunakan struktur loose reference yang menyimpan setiap referensi sebagai file terpisah
  • Pada repositori dengan puluhan juta referensi, pendekatan ini tidak efisien dan menimbulkan masalah case sensitivity pada filesystem serta inkonsistensi konkurensi
• Reftable adalah struktur tabel berbasis format biner yang memungkinkan pembaruan atomik dan pengelolaan referensi yang efisien
  • Dalam kasus repositori GitLab dengan 20 juta referensi, file packed-refs lama perlu ditulis ulang sebesar 2GB
• Di Git 3.0, Reftable akan menjadi backend default, dan pengguna dianjurkan menggunakan perintah Git alih-alih mengakses file secara langsung

Peningkatan penanganan file besar

• Git efisien untuk kompresi file teks, tetapi menjadi tidak efisien untuk modifikasi file biner karena seluruh objek harus dibuat ulang
  • Menurut analisis GitLab, 75% ruang repositori ditempati oleh file biner berukuran 1MB atau lebih
• Fitur Large-object promisors menyimpan objek besar di remote storage terpisah sehingga dapat dikirim melalui CDN atau API S3
  • Implementasi protokol telah selesai di Git 2.50~2.52, dan kini berada pada tahap dapat digunakan di sisi klien
• Database objek pluggable akan memperkenalkan format penyimpanan khusus biner untuk mendukung penyimpanan inkremental
  • Antarmuka database objek terpadu diperkenalkan di Git 2.53, dan proof of concept (PoC) diperkirakan hadir di 2.54

Peningkatan antarmuka pengguna

• Perintah Git telah lama dikritik karena kompleks dan kurang konsisten, sementara Jujutsu (JJ) berbasis Rust muncul sebagai alternatif
  • Jujutsu menawarkan pemindahan ulang histori otomatis, penanganan konflik sebagai data, dan cara memperlakukan commit seperti draf
• Git sedang mengadopsi sebagian kelebihan Jujutsu tanpa merusak workflow yang ada
  • Di Git 2.54, perintah git history split dan git history reword dijadwalkan ditambahkan
  • Ke depan, lebih banyak subperintah pengeditan histori direncanakan akan ditambahkan
• Steinhardt menekankan bahwa Git sedang belajar melalui persaingan, dan modernisasi UI serta peningkatan usability terus berlangsung

[GN⁺]

Komentar Hacker News

• Git benar-benar perangkat lunak yang indah, tetapi juga memperlihatkan kompleksitas yang berpusat pada programmer apa adanya
  Saya pernah mencoba mengajarkan Git kepada orang-orang non-teknis, dan mereka tidak benar-benar bisa memanfaatkan kekuatan halus dari fitur-fiturnya sepenuhnya
  Situs seperti Learn Git Branching adalah sumber belajar yang luar biasa. Akan bagus jika UX seperti ini menyatu ke dalam pengalaman bawaan Git — seperti default yang intuitif dan alur belajar yang bertahap
  Belakangan ini, pengalaman seperti itu bisa dengan mudah diberikan lewat agent CLI seperti Claude, Codex, dan OpenCode. Namun akan jauh lebih mudah jika Git sendiri menyediakan abstraksi yang lebih mudah diakses

  • Masalahnya bukan Git menampilkan kompleksitas, melainkan ia mengekspresikan kompleksitas itu dengan istilah dan konsep yang keliru, serta dokumentasi yang berantakan

• Saya sangat menantikan Git 3.0, tetapi pada saat yang sama juga siap untuk langsung kecewa 😅
  jj sangat membantu para pengguna Git. Ia menunjukkan bahwa frontend VCS yang lebih intuitif itu memungkinkan

  • Semakin banyak kompetisi, semakin banyak dorongan positif bagi ekosistem

• Saya pernah melihat kasus di GitLab di mana file packed-refs berukuran 2GB ditulis ulang setiap beberapa detik, dan saya sama sekali tidak paham “kenapa hal seperti itu bisa terjadi”

  • Dan sejujurnya, saya juga tidak tahu apakah ada alasan mengapa Git atau orang itu perlu peduli dengan situasi seperti itu

• Menyimpan file berukuran besar di luar tampak seperti selangkah menuju model terpusat, tetapi itu bertentangan dengan filosofi desain awal Git

  • Tidak juga. Itu hanya soal model pengalamatan dan antarmuka. Anda bisa memakai penyimpanan terpusat, tetapi juga bisa memakai penyimpanan terdistribusi seperti IPFS
  • Benar. Git adalah DVCS, bukan DVFS serbaguna. Saya membutuhkan DVFS untuk menyimpan dokumen, jadi saya membuatnya sendiri. Sederhana, cepat, dan bekerja dengan baik sesuai tujuannya

• Transisi untuk meninggalkan SHA1 memakan waktu terlalu lama
  Fungsi hash seharusnya sejak awal dirancang dengan struktur yang lebih modular

• Menurut saya Git perlu memiliki fitur pelacakan lisensi perangkat lunak per commit

  • Saya tidak sepenuhnya paham maksudnya, tetapi itu bukan tugas Git. Git hanyalah sistem manajemen kode sumber, dan fitur tambahan seharusnya diimplementasikan lewat alat ekstensi seperti git-annex
  • Git justru akan menjadi lebih buruk jika memiliki fitur seperti itu. Commit sudah bisa menyimpan data arbitrer, jadi metadata yang dibutuhkan tinggal dimasukkan ke dalam commit lalu diproses dengan alat terpisah
  • Bisa memakai trailer seperti pada kode yang dibantu LLM
    Contoh: Co-Authored-By: Whatever LLM, License: WTFPL