Oops Salah Commit Besar Begini Cara Hapus File di Git History Selamanya

Pernah nggak sih kamu lagi asyik coding, fokus banget sama fitur yang lagi dikerjain, terus tiba-tiba ada momen "jantung copot"? Itu lho, momen ketika kamu baru sadar kalau kamu nggak sengaja nge-commit file yang super sensitif atau ukurannya jumbo banget ke repository Git publik. Misalnya, file .env yang isinya secret key database, atau folder node_modules (duh!) yang harusnya diabaikan, atau bahkan file media mentah sebesar 500MB.

Kamu panik, langsung hapus file itu dari folder, dan bikin commit baru dengan pesan "Fix: remove sensitive file."

Stop! Sayangnya, cara itu cuma menghapus file dari snapshot terbaru. File sensitif itu, beserta semua isinya, masih tersimpan rapi dan abadi di dalam history Git kamu. Artinya, siapa pun yang mengklon repo kamu, bisa dengan mudah mengakses versi file yang terhapus itu.

Dalam dunia pengembangan profesional—khususnya di standar tinggi yang diterapkan Javapixa Creative Studio—kebersihan dan keamanan repository itu mutlak. Jika kamu bekerja di Javapixa, kami pasti akan meminta kamu membereskannya sampai tuntas.

Nah, artikel ini akan jadi panduan lengkapmu untuk membersihkan "dosa" Git itu. Kita akan bicara tentang bagaimana cara menghapus file dari sejarah Git selamanya. Ini bukan sekadar menghapus commit terakhir, tapi benar-benar menulis ulang sejarah, memastikan file sensitif itu hilang tanpa jejak.

Peringatan Keras: Menulis ulang sejarah Git adalah operasi yang serius. Selalu lakukan backup sebelum memulai. Jangan pernah melakukan ini pada branch atau repository yang sedang aktif dikerjakan banyak orang tanpa komunikasi yang jelas, karena ini akan memaksa semua rekan timmu untuk melakukan re-clone atau rebase yang rumit.

*

Kenapa Menghapus dari History Itu Krusial?

Sebelum kita masuk ke perintah teknisnya, kita harus paham dulu kenapa upaya "Hapus dan Commit Lagi" itu nggak mempan:

  1. Keamanan (Security Leak): Ini yang paling penting. Jika kamu commit API key, token, atau credential lainnya, data itu terekam. Walaupun kamu hapus di commit berikutnya, seseorang yang tahu cara menjelajahi history Git (misalnya menggunakan git checkout [hash commit sebelumnya]) masih bisa melihat data rahasiamu.
  2. Ukuran Repository (Bloat): File besar, apalagi yang ukurannya ratusan MB, akan membuat repository kamu bengkak. Setiap kali ada yang mengklon proyek, mereka harus mengunduh file besar itu, bahkan jika file itu sudah tidak ada di versi terbaru. Ini memperlambat proses deployment dan onboarding rekan tim baru.

Jadi, tujuan kita adalah menghapus file tersebut dari semua tree dan blob di Git, bukan hanya di working directory terbaru.

*

Metode Lama yang Mulai Ditinggalkan: git filter-branch

Selama bertahun-tahun, git filter-branch adalah alat standar untuk menulis ulang sejarah Git. Alat ini sangat kuat, tapi juga sangat lambat dan ribet. Untuk repository modern yang ukurannya sudah GB-an, menjalankan git filter-branch bisa memakan waktu berjam-jam, bahkan seharian.

Karena kompleksitas dan performanya yang buruk pada repo besar, Git sendiri menyarankan kita untuk beralih ke alat yang lebih modern dan cepat.

*

The Modern Hero: BFG Repo-Cleaner

Lupakan git filter-branch. Hari ini, senjata andalan kita untuk membersihkan sejarah Git adalah BFG Repo-Cleaner.

BFG dirancang khusus untuk dua hal: menghapus blob (file besar) dan menghapus teks rahasia yang tidak sengaja ter-commit. BFG ini jauh lebih cepat—10 hingga 100 kali lebih cepat dari git filter-branch—dan sintaksnya jauh lebih mudah dipahami, apalagi buat anak muda yang nggak suka hal-hal berbelit.

Syarat: BFG ditulis dengan Java, jadi kamu harus punya Java Runtime Environment (JRE) terinstal di komputermu.

Langkah 1: Persiapan dan Instalasi BFG

Pertama, unduh file .jar BFG Repo-Cleaner.

Kedua, kamu perlu menyiapkan repository kamu untuk dibersihkan. Jangan pernah menjalankan BFG langsung pada repository yang sedang kamu kerjakan. Kita harus bekerja pada klon mirror.

  1. Pindah ke Direktori Aman: Pindah ke folder di luar proyek utamamu.
  2. Klon Repository sebagai Mirror:

bash
   git clone --mirror https://github.com/user/nama-repo.git

Perintah --mirror memastikan kita mendapatkan semua refs, termasuk branch dan tag, sehingga BFG bisa memproses seluruh sejarah.

  1. Masuk ke Direktori Mirror:

bash
   cd nama-repo.git

Langkah 2: Menentukan File yang Harus Dihapus

Ada dua skenario umum:

Skenario A: Menghapus File Tertentu berdasarkan Nama

Jika kamu tahu persis nama file sensitif yang kamu commit (misalnya config/database.yml atau .env):

bash
java -jar /path/ke/bfg.jar --delete-files namafile.txt --delete-files .env

(Ganti /path/ke/bfg.jar dengan lokasi file BFG yang kamu unduh.)

Skenario B: Menghapus File yang Lebih Besar dari Ukuran Tertentu

Ini berguna jika kamu nggak tahu nama file-nya tapi tahu kalau kamu nggak sengaja nge-push file gambar besar atau zip yang ukurannya di atas 50MB.

bash
java -jar /path/ke/bfg.jar --strip-blobs-bigger-than 50M

Tips: BFG akan membuat file .bfg-report/ yang akan menunjukkan file apa saja yang telah diubah atau dihapus, sehingga kamu bisa memeriksanya.

Langkah 3: Eksekusi dan Penulisan Ulang Sejarah

Setelah BFG selesai berjalan, ia akan membersihkan history di repository mirror lokal kamu. BFG sudah melakukan 99% pekerjaan berat, tapi sekarang kamu perlu menjalankan perintah Git standar untuk membersihkan referensi lama yang masih tersisa dan membuang sisa-sisa data yang sudah tidak dipakai.

Jalankan perintah ini di dalam folder mirror (misalnya nama-repo.git):

bash
git reflog expire --expire=now --all && git gc --prune=now --aggressive

Penjelasan Perintah:

  • git reflog expire --expire=now --all: Ini menghapus semua referensi lama yang disimpan Git secara internal.

git gc --prune=now --aggressive: Ini adalah perintah "Garbage Collection." Git akan mengumpulkan semua objek yang kini menjadi dangling (tidak terhubung ke history manapun) dan menghapusnya. Ini memastikan file-file yang tadinya besar benar-benar hilang dari database* Git lokal.

Selamat, sejarah lokalmu sudah bersih!

*

Langkah Terakhir dan Paling Berbahaya: Force Push

Setelah kamu yakin history lokalmu bersih dan file sensitif sudah hilang, saatnya memberitahu remote (misalnya GitHub atau GitLab) bahwa sejarah lamanya harus diganti total dengan sejarah barumu.

Ini harus dilakukan dengan Force Push.

bash
git push --force

Penting:

  1. Force push akan menimpa seluruh history di remote branch tersebut. Pastikan kamu hanya melakukan force push ke branch yang kamu bersihkan (misalnya main atau develop).
  2. Jangan pernah force push ke branch yang baru saja diperbarui oleh rekan tim, kecuali kamu yakin history baru kamu mencakup perubahan mereka. Komunikasi adalah kunci!

Sebagai studio kreatif yang mengutamakan kolaborasi, Javapixa selalu menekankan pentingnya notifikasi.

Checklist Setelah Force Push

Setelah kamu berhasil force push dan remote history sudah di-update, ada beberapa hal yang wajib kamu lakukan:

  1. Informasikan Rekan Tim: Ini adalah langkah wajib. Semua rekan tim yang sedang mengerjakan branch tersebut harus menghapus repository lokal mereka dan mengklon ulang, atau setidaknya melakukan hard reset dan pull dari remote baru. Jika mereka mencoba pull biasa, mereka akan mengalami konflik history yang parah.

Contoh Pesan: "Perhatian tim! Saya baru saja melakukan penulisan ulang history di branch main untuk menghapus file sensitif/besar. Mohon lakukan git fetch --all dan git reset --hard origin/main, atau lebih baik lagi, hapus folder lokal dan re-clone."

  1. Periksa di Remote: Cek langsung di platform Git (GitHub, GitLab, Bitbucket). Apakah ukuran repository sudah mengecil? Apakah file yang kamu cari sudah benar-benar hilang?
  2. Periksa Tag: Jika repository kamu menggunakan tag, kamu mungkin perlu men-delete tag lama yang merujuk pada commit yang sudah dihapus, lalu me-push tag baru.

bash
   git push origin --tags # untuk push tag baru

Bagaimana Jika Saya Tidak Sengaja Commit Teks Sensitif (Bukan File)?

Kadang yang kamu commit bukan file, tapi hanya sebuah string rahasia yang kamu ketik di salah satu file kode, dan string itu muncul di banyak commit sebelumnya. BFG juga punya solusinya:

bash
java -jar /path/ke/bfg.jar --replace-text 'string rahasia yang sensitif'

Atau, kamu bisa menggunakan file teks untuk menampung semua string yang ingin kamu hapus (sangat disarankan, agar string sensitif itu tidak terekam di command line history):

bash
java -jar /path/ke/bfg.jar --replace-text-from file-dengan-string-rahasia.txt

BFG akan mengganti semua kemunculan teks sensitif itu di seluruh history dengan REMOVED. Ini adalah cara yang sangat ampuh untuk membersihkan history dari kebocoran token.

Mengapa BFG Lebih Disukai oleh Profesional seperti Javapixa?

Sebagai tim yang mengedepankan efisiensi dan kualitas, Javapixa Creative Studio memilih BFG karena:

  1. Kecepatan Absolut: Pada proyek berskala besar milik klien kami, filter-branch bisa memakan waktu seharian. BFG menyelesaikannya dalam hitungan menit. Waktu adalah uang, dan waktu deployment adalah segalanya.
  2. Fokus pada Masalah: BFG hanya fokus pada blob dan tree, yang merupakan tempat file sensitif bersembunyi. Ia tidak terlalu peduli dengan struktur commit message atau branch lainnya kecuali yang diperlukan, menjadikannya lebih aman dari kesalahan manusia.
  3. Sintaks yang Jelas: Perintahnya sangat mudah dibaca dan dipahami, mengurangi risiko salah ketik perintah yang fatal.

Menguasai teknik membersihkan sejarah Git adalah salah satu ciri developer yang profesional. Ini menunjukkan bahwa kamu tidak hanya bisa menulis kode, tapi juga mengelola version control dengan standar keamanan dan efisiensi tertinggi.

Jika kamu adalah developer yang mencari lingkungan kerja yang menjunjung tinggi standar teknis seperti ini, atau jika kamu adalah klien yang mencari tim pengembangan aplikasi atau website yang sangat detail dan peduli terhadap kebersihan kode dan keamanan repository, Javapixa Creative Studio siap menjadi mitra kamu. Kami tidak hanya membangun produk, kami membangunnya dengan fondasi teknis yang solid dan bersih, bahkan hingga ke history Git paling dalam. Sekarang, kamu bisa kembali coding dengan tenang, karena file sensitif itu sudah benar-benar musnah dari sejarah. Happy coding!