Bagaimana kami mengurangi ukuran git monorepo JavaScript sebesar 94%

• 1JS, monorepo JavaScript berskala besar milik Microsoft, memiliki sangat banyak kode dan kontribusi. Repo yang baru dikloning belakangan ini mencapai 178GB.
• Ukuran repo terlalu besar sehingga beberapa pengguna di Eropa bahkan tidak bisa mengkloningnya.

Pelajaran #1

• Saat bergabung ke repo ini beberapa tahun lalu, kami menemukan bahwa repo tumbuh dengan cepat. Saat pertama kali dikloning ukurannya sekitar 1~2GB, tetapi beberapa bulan kemudian sudah mencapai 4GB.
• Kami menggunakan alat git-sizer untuk memeriksa blob besar, yang biasanya terjadi ketika file biner tidak sengaja di-check-in. Ini dapat dicegah dengan menggunakan fitur pembatasan ukuran check-in di Azure DevOps.
• Masalah juga muncul karena file perubahan Beachball tidak dihapus. Mirip dengan Changesets, ini digunakan untuk secara otomatis menaikkan rentang semver paket.
• Kami belajar untuk tidak menyimpan ribuan file dalam satu folder. Untuk mengatasinya, kami mengirim pull request ke Beachball agar beberapa perubahan dapat diproses dalam satu file, dan menulis pipeline untuk membersihkan folder perubahan secara berkala.

Pelajaran #2

• Branch versioned, yang merupakan mirror dari main, makin sulit untuk dikloning. Meskipun yang berubah hanya file CHANGELOG.md dan CHANGELOG.json, branch ini tetap membawa tambahan 125GB data git.
• Kami menemukan bahwa kode packing lama yang di-check-in oleh Linux Torvalds melakukan kompresi dengan hanya membandingkan 16 karakter terakhir dari nama file. Akibatnya, git berulang kali mendorong seluruh file dengan membandingkannya terhadap file CHANGELOG.md milik paket lain.
• Kami mengurangi ukuran repo dengan perintah git repack -adf --window=250, lalu dengan perintah baru git repack -adf --path-walk menguranginya dari 178GB menjadi 5GB.
• Kami menambahkan pengaturan git config --global pack.usePathWalk true agar delta yang benar dibuat saat git push.

Penutup

• Jika file dengan nama panjang seperti CHANGELOG.md sering diperbarui dalam monorepo besar, fitur path walk patut diperhatikan.
• Dengan perintah git survey, kita bisa melihat file teratas berdasarkan ukuran disk, direktori teratas berdasarkan ukuran yang mengembang, dan sebagainya.
• Microsoft sedang mengembangkan solusi untuk penskalaan repositori dan menyediakannya ke seluruh dunia.

Ringkasan GN⁺

• Artikel ini membagikan pengalaman tentang cara mengurangi ukuran git pada monorepo JavaScript berskala besar. Secara khusus, masalah pada kode packing git lama berhasil diselesaikan sehingga ukuran repo berkurang drastis.
• Artikel ini memberikan informasi yang berguna untuk menyelesaikan masalah terkait git yang dapat muncul pada proyek berskala besar. Secara khusus, dijelaskan cara menangani masalah akibat pembaruan berulang pada file seperti CHANGELOG.md.
• Proyek dengan fungsi serupa antara lain Buck dari Facebook dan Bazel dari Google. Alat-alat ini dapat membantu mengelola codebase berskala besar secara efisien.

[GN⁺]

Komentar Hacker News

• Perintah git-survey yang baru belum dimasukkan ke git.git. Itu ditambahkan di fork git milik Microsoft

• Saat meng-clone nixpkgs, opsi --window 250 mengurangi ukurannya menjadi 1.7GB. Opsi --path-walk di fork git Microsoft menguranginya menjadi 1.9GB

  • Kedua opsi menurunkannya menjadi kurang dari setengah ukuran awal
  • Akan bagus jika ini bisa dijalankan di GitHub, dan lebih bagus lagi jika di-host dengan cara yang memungkinkan orang mengaturnya

• Beberapa pengguna di Eropa mengatakan mereka tidak bisa meng-clone repositori besar. Tampaknya clone tidak akan memungkinkan sampai perubahan dilakukan di sisi server

• Masalah terjadi karena kesalahan di mana nama file tidak menyertakan seluruh path. Yang diperiksa hanya 16 karakter terakhir

• Derick Stolee menulis blog tentang struktur internal git. Ada banyak hal yang bisa dipelajari tentang cara mengurangi ukuran git clone di lokal dan CI

• Mengutak-atik Git memang menyenangkan, tetapi saya penasaran apakah ada cara untuk tidak memasukkan 2.500 paket ke dalam monorepo

• Akan lebih baik jika Microsoft menggunakan Azure DevOps untuk kebutuhannya sendiri. Terlihat seperti layanan Azure hanya menyediakan konektor native ke GitHub

• Memiliki seseorang di dekat kita yang sangat memahami struktur internal Git adalah keuntungan besar saat bekerja di proyek besar

• Terima kasih untuk postingan ini. Ini sangat membantu perangkat lunak open source. Microsoft, GitHub, dan GitLab memberikan banyak hal baik

• Saya ingin lebih memahami masalah pemeriksaan 16 karakter terakhir dan seluruh path. Saya penasaran bagaimana itu terhubung dengan kompresi delta, indeks paket, dan indeks multi-paket