git-annex - Alat pengelolaan file berukuran besar untuk pengguna Git

• git-annex adalah alat yang memungkinkan Anda mengelola file besar tanpa menaruh kontennya langsung di repositori Git
• Menjalankan sinkronisasi, pencadangan, dan pengarsipan di lingkungan offline maupun online, serta menjamin keamanan dengan checksum dan enkripsi
• Menerapkan sifat terdistribusi Git pada file berukuran besar untuk menyederhanakan pelacakan lokasi dan transfer antar drive, server, dan cloud
• Cocok untuk pengguna yang berfokus pada CLI, sementara git-annex assistant menyediakan pengalaman seperti sinkronisasi folder untuk pengguna umum
• Merupakan alat yang memperluas alur kerja pengarsipan dan pemindahan melalui format repositori sederhana untuk pelestarian jangka panjang dan beragam special remotes

---

Gambaran umum

• git-annex adalah alat pengelolaan file besar yang menyimpan konten file di luar Git dan hanya mengelola metadata serta informasi lokasi dengan Git
  • Hasilnya, riwayat commit tetap ringan sambil tetap memungkinkan penyimpanan dan pemindahan biner berukuran besar secara fleksibel
  • Menjamin integritas dan kerahasiaan dengan checksum serta dukungan enkripsi
• Menjalankan sinkronisasi, pencadangan, dan pengarsipan baik secara offline maupun online, serta menyediakan pengelolaan jumlah salinan file yang sama dan pencatatan log di antara penyimpanan yang terdistribusi
• Dioptimalkan untuk pengguna command line, tetapi melalui git-annex assistant, pengguna umum juga dapat memakainya dengan mudah dalam bentuk sinkronisasi folder
• Menyediakan dokumen walkthrough bagi pengguna baru agar bisa cepat mempelajari instalasi dan alur dasar

Kasus penggunaan: Archivist (pengguna berorientasi arsip)

• Saat mengoperasikan beberapa drive arsip offline, Anda tetap bisa menelusuri dan menata ulang semua file seolah-olah satu kesatuan dalam satu pohon direktori
  • Bahkan jika konten file berada di drive offline, penataan ulang dan commit tetap bisa dilakukan melalui indeks dan pointer tanpa risiko penghapusan nyata
• Saat file tertentu dibutuhkan, alat ini memberi tahu di drive mana file itu berada dan memungkinkan Anda dengan mudah membuatnya tersedia
  • Setiap drive saling berbagi informasi lokasi untuk memahami keseluruhan status arsip
• Menggunakan format repositori sederhana sehingga aksesibilitas file tetap terjaga dalam jangka panjang bahkan tanpa menggunakan git-annex maupun git
• Dengan pekerjaan cron, file baru dapat diarsipkan otomatis pada malam hari, dan salinan yang disengaja maupun tidak disengaja dicatat untuk menjadi dasar menentukan kapan replikasi diperlukan

Kasus penggunaan: Nomad (pengguna berorientasi mobilitas)

• Mengelola penyimpanan yang heterogen seperti laptop, drive USB/flash drive portabel, server jarak jauh, dan penyimpanan cloud terenkripsi secara konsisten seperti Git remote
  • Saat sedang berpindah tempat, Anda bisa menumpuk antrian unduhan di server lalu menjalankan transfer sebenarnya di tempat dengan kualitas koneksi yang lebih baik, mendukung alur transfer tertunda
• Memungkinkan alur kerja yang ramah offline seperti salin seketika dari USB lalu dipakai secara lokal untuk menghemat baterai dan kebutuhan serupa
• Setelah selesai digunakan, Anda dapat menentukan apa yang dipertahankan atau dihapus untuk merebut kembali ruang lokal, lalu menyinkronkan perubahan ke server pada sinkronisasi berikutnya
• Melalui special remotes dan pipeline transfer, alat ini mewujudkan perpindahan data yang fleksibel pada berbagai backend penyimpanan dan kondisi jaringan

Fitur inti dan manfaat

• Mewujudkan penyimpanan jangka panjang yang aman dengan jaminan integritas berbasis content addressing dan checksum serta dukungan penyimpanan terenkripsi
• Melalui pelacakan lokasi (location tracking), Anda dapat mengetahui dengan jelas lokasi penyimpanan, jumlah salinan, dan ketersediaan tiap file
• Menerapkan model version control terdistribusi pada file besar untuk mengurangi ketergantungan pada penyimpanan terpusat dan memperoleh ketahanan offline
• Menyediakan pengalaman sinkronisasi folder melalui mode assistant, sehingga pengguna yang belum terbiasa dengan CLI tetap mendapatkan kemudahan setara drag-and-drop

Ringkasan kelebihan

• git-annex hanya mengelola referensi file dengan git, sehingga sangat cocok untuk menangani file berukuran besar tanpa beban berlebih
• Melalui arsitektur terdistribusi, file dapat dipindahkan, disimpan, disinkronkan, dicadangkan, dan dikelola versinya secara bebas di berbagai perangkat dan lokasi
• Sangat unggul dalam integrasi dan skalabilitas, terutama untuk skenario offline dan pelestarian jangka panjang, maupun pengelolaan data yang dinamis lintas perangkat dan cloud
• Cocok juga untuk pengguna campuran antara orientasi arsip dan mobilitas, serta berguna bagi organisasi maupun individu lewat pengelolaan kebijakan salinan dan diversifikasi backend
• Alat ini memperluas sifat terdistribusi dan portabilitas Git ke data berukuran besar, sehingga menurunkan risiko operasional dan beban kerja dalam tugas penyimpanan jangka panjang serta pemindahan data

[GN⁺]

Komentar Hacker News

• Saya memakai git-annex untuk mengelola data di semua drive saya. Ia otomatis melacak file ada di drive mana, menjaga jumlah salinan tetap memadai, dan memverifikasi checksum untuk semua file. Drive yang sedang offline juga tetap ditangani dengan baik. git-annex mungkin terasa agak sulit dipahami di awal, jadi saya sarankan membuat satu repositori sementara, lalu mengikuti walkthrough sambil praktik langsung. Berbagai workflow juga layak dilihat

  • Penasaran, seberapa banyak data yang Anda simpan? Saya mengelola sekitar 100 ribu hingga 1 juta file, dengan data foto beberapa TB, di ZFS memakai git-annex. Awalnya tidak ada masalah, tetapi belakangan ini makin lambat sampai setiap perintah bisa memakan 5–30 menit. Saya bingung apakah ini karena ZFS, git-annex, atau disknya

  • Saya sudah lama berpikir untuk mengelola data dengan git-annex, tetapi ada cukup banyak gesekan saat ingin menghapus file sepenuhnya dan saya juga menemui beberapa masalah lain. Kalau ada waktu, saya ingin tahu apakah Anda bisa berbagi bagaimana cara Anda memakainya

• Tidak tertulis di halaman itu, tetapi git-annex dibuat oleh Joey Hess. Ia juga membuat moreutils dan etckeeper

  • Fakta yang menurut saya lebih terkenal adalah bahwa ia telah menjadi kontributor inti Debian selama puluhan tahun sejak 1996. Sebagian besar Linux seperti yang kita kenal sekarang lahir dari ujung jarinya

• Baru-baru ini ada diskusi tentang fitur native baru Git untuk pengelolaan objek besar di sini

  • Sebagai tambahan, saya juga menjelaskan di komentar mengapa menurut saya diskusi itu tidak terlalu relevan. annex sebenarnya berada di ranah yang agak berbeda dari masalah “large files in git”. git-annex lebih mudah dipahami jika dilihat sebagai pendekatan yang mendistribusikan masalah penyimpanan “sisi server” ala LFS dan sejenisnya dengan cara yang native Git

• Hal yang saya sesalkan dari git-annex adalah Haskell. Bukan karena saya membenci bahasanya, tetapi saya terkejut melihat betapa banyak dependensi yang harus dipasang. Banyak di antaranya tidak dibutuhkan untuk hal lain, dan konflik versi juga sering muncul di berbagai aplikasi. Ini terasa sangat berat terutama jika dipasang lewat manajer paket sistem. Hanya dengan memasang annex dan pandoc saja, saya terus mendapat puluhan pembaruan paket Haskell setiap hari. Kalau Anda memakai distro yang membangun dari source, itu mimpi buruk. Sebenarnya saya rasa sebagian besar ini aman saja jika ditautkan secara statis. Namun di kalangan Haskell hal ini disebut sebagai akibat dari modularisasi library yang sangat halus. Tapi ada prioritas lain juga, seperti administrasi sistem, dan saya tidak pernah mengalami masalah seperti ini di Rust, Go, Zig, C, atau C++. Saya tidak memusuhi ekosistem atau pengguna Haskell, saya juga berniat mempelajarinya. Tapi saya penasaran mengapa masalah ini ada dan apa solusinya

  • Tooling Haskell sebenarnya sudah mendukung static linking. Saya mengelola stack Haskell untuk Solus, dan pandoc hanya bergantung pada libc sementara semua paket Haskell dibundel secara statis ke dalam biner lalu didistribusikan seperti Rust. Jadi ini sangat mungkin dilakukan. Di Solus kami memang memakai static linking karena dependensinya terlalu banyak. Menurut saya ini soal keputusan maintainer distro

  • Soal bagian “sebagian besar ini aman saja jika ditautkan secara statis”, bukankah pada akhirnya itu cuma isu kebijakan manajer paket kalau kita bicara repo distro?

  • Bahkan sebagai developer Haskell full-time, saya juga punya rasa enggan yang serupa terhadap paket Haskell yang tidak di-static-link. Di AUR sudah ada versi yang di-static-link, jadi setidaknya ini bukan hal yang mustahil. Saya sendiri belum pernah menyelidiki kenapa para packager tetap bersikeras memakai dynamic linking. Biasanya dynamic linking memang bisa masuk akal untuk distribusi software internal, tapi mungkin pendekatan itu diproyeksikan secara tidak perlu ke distro

  • Penasaran Anda memakai manajer paket apa. Di sistem berbasis apt saya belum pernah mengalami masalah akibat Haskell

  • Setiap kali pacman -Syu, setengah dari pembaruannya adalah paket Haskell dan itu menjengkelkan. Mungkin penyebabnya pandoc atau shellcheck

• git-annex benar-benar teknologi yang keren. Tetapi kesan saya, ia paling cocok untuk repositori pengguna tunggal. Misalnya satu orang yang mengelola data pribadinya sendiri—file, dokumen, musik—lintas berbagai perangkat. Saya pernah memakainya untuk sinkronisasi pada repositori kolaboratif yang menangani file besar, tetapi pendekatan branch “magic”-nya tidak skala dengan baik

  • Mungkin berbeda untuk tiap orang, tetapi di institusi kami justru bekerja dengan baik. Kami adalah lembaga arsip digital dan telah memakai git-annex sebagai backend repositori internal selama lebih dari 10 tahun. Staf kami sekitar 15–20 orang, tetapi kami menangani lebih dari 30 TB data dan 750 ribu file (biner + metadata), tersebar di ratusan repositori, tanpa masalah berarti

• Saya memakai forgejo self-hosted. Sampai sekarang saya belum melihat di mana git-annex lebih unggul daripada LFS, dan rasanya penyiapannya juga tidak akan mudah. Saya juga kurang suka git-annex ditulis dalam Haskell, dan saya juga menemukan klaim bahwa ia sekitar 50% lebih lambat—meski sumbernya hanya satu jadi saya belum yakin itu informasi yang bisa dipercaya. Mungkin ada alasan kenapa perintahnya rumit, tetapi ia tidak punya kenyamanan seperti LFS, di mana Anda hampir bisa memahami semuanya hanya dari .gitattributes. Saya juga tidak merasakan transparansi seperti .gitattributes di git-annex. Dan kalau bahkan tidak ada tutorial yang menunjukkan padanannya untuk 'git lfs ls-files', saya rasa saya tidak akan terlalu tertarik. Saya terbiasa mengecek dengan 'git status' dan 'git lfs ls-files'

  • Kalau lambat, itu bukan karena Haskell. git-annex adalah alat backup terdistribusi, jadi yang membuatnya lambat adalah perilakunya yang sangat menekankan I/O dan pelestarian data. Misalnya saat memakai perintah drop, ia harus memeriksa secara real-time ke semua remote apakah konten tersebut ada, sehingga jadi lambat. Dengan opsi seperti --fast dan sejenisnya, Anda bisa hanya mempercayai metadata lokal dan melewati proses verifikasi, sehingga jauh lebih cepat (tetapi sedikit lebih berisiko)

  • LFS dan git-annex memang ditujukan untuk kebutuhan yang agak berbeda. LFS cocok untuk contoh pengembangan yang mencampurkan file besar dalam repositori git, misalnya pengembangan game. git-annex lebih cocok saat Anda ingin membackup data penting, misalnya menyimpan kumpulan file besar seperti folder musik di banyak lokasi. Saya memakainya untuk kebutuhan yang kedua

  • Ada soft-fork Forgejo yang mendukung git-annex: forgejo-aneksajo

  • Repositori terbesar yang saya kelola dengan git-annex berukuran beberapa TB dan tersebar di beberapa sistem, dengan banyak file berukuran lebih dari 10 GB. Jika yang dicari penulis adalah padanan git-lfs-ls-files, maka di git-annex git annex list --in here mungkin menjalankan peran yang mirip

• Saya suka bahwa dokumentasi command-line-nya menaruh contoh penggunaan nyata di bagian paling depan. Banyak alat lain biasanya malah mulai dari penjelasan opsi yang membingungkan dan nyaris tidak pernah dipakai, dan itu selalu terasa mengecewakan

• GitHub tidak mengadopsi git-annex dan malah menerapkan NIH (Not Invented Here) ala Microsoft pada LFS

  • Saya juga merasa git-annex lebih elegan, tetapi kompatibilitas lintas platformnya lebih lemah. Sebagai catatan, LFS lahir dari kolaborasi GitHub dan Bitbucket (tepatnya saya lupa forge yang mana). Satu pihak menyumbang implementasi, pihak lain menyumbang nama, lalu mereka menggabungkannya setelah bertemu di konferensi Git. Hal yang paling saya sesalkan sekarang adalah batasan yang diterapkan GitHub pada proyek besar. Ditambah lagi ada kebijakan “semua objek harus diambil ke lokal sebelum bisa push”, sehingga komunitas pengembang yang cukup besar cepat sekali menabrak limit. Catatan: saya pernah berkontribusi ke git-lfs

  • (Sejujurnya) pendekatan NIH GitHub merugikan di segala sisi. Ada pembicara yang sangat menyukai git-annex: Staying in Control of your Scientific Data with Git Annex by Yann Büchau

• Ironisnya, akhir pekan lalu saya menghabiskan satu hari untuk membuat sistem version control file besar saya sendiri. Saya sebegitu tidak sukanya pada git-annex. Ia mengubah file menjadi blob dan membuat file system membengkak. Tujuan utama saya adalah sinkronisasi antar file terdistribusi, dan saya sendiri tidak peduli pada version control—saya malah tidak paham kenapa file besar perlu version control. Dengan AI dan Python, Anda bisa membuat helper method untuk melakukan hash file, membuat lookup table, lalu memakai rclone untuk menyinkronkan source. Ada banyak cara yang jauh lebih sederhana dan efisien

• Saya memakainya selama beberapa tahun, dan keunggulan terbesarnya adalah integrasi dengan penyedia cloud storage dan backup. Namun fitur integrasi itu selalu terasa rapuh dan bergantung pada plugin pihak ketiga yang tidak terawat. Dulu bahkan pernah ada bug inkonsistensi data, dan akhirnya saya menyerah. Saya penasaran apakah ada perbaikan dalam 5 tahun terakhir

  • Menurut saya itu tergantung jenis penyedia cloud storage-nya. Yang mendukung protokol standar resmi seperti S3, webdav, sftp, dan sejenisnya punya posisi lebih baik. Belakangan ini, special remote berbasis rclone sudah dibangun langsung ke dalam git-annex, dan ini tampaknya lebih terawat dibanding remote pihak ketiga lama serta bisa terhubung dengan hampir semua cloud remote yang didukung rclone