Git Revert vs Reset: Mana yang Menyelamatkan Riwayat Anda?

TL;DR: git revert menambahkan commit baru yang membatalkan commit lama — riwayat utuh, aman untuk branch yang sudah ditarik orang lain. git reset menggeser pointer branch ke belakang — riwayat ditulis ulang, hanya aman pada commit yang belum Anda push. Pakai revert di branch bersama, reset untuk membersihkan pekerjaan lokal. reset --hard juga menghapus perubahan working-tree yang belum di-commit; itulah perintah yang melahap kerja sungguhan.

Apa bedanya git revert dan git reset?

Keduanya membuat proyek Anda tampak seolah sebuah commit masa lalu tak pernah terjadi. Perselisihannya ada pada caranya:

• git revert <sha> menghitung patch invers dari sebuah commit lalu meng-commit-nya. Riwayat Anda bertambah satu commit yang berarti “batalkan yang itu”. Commit yang buruk tetap ada di log, diikuti pembatalannya. SHA commit lain tidak tersentuh.
• git reset <sha> menggeser pointer branch saat ini ke <sha>. Commit setelahnya terlepas — masih ada di object database sampai garbage collection, tetapi tidak lagi terjangkau dari branch mana pun atau git log.

Yang satu tidak menulis ulang apa pun, yang lain berpura-pura tidak terjadi apa-apa. Satu sifat itulah yang menentukan mana yang dibutuhkan tiap situasi:

# Demo: repo sekali pakai yang bisa dijalankan
git init /tmp/revert-vs-reset && cd /tmp/revert-vs-reset
echo one > file.txt && git add . && git commit -m "one"
echo two > file.txt && git add . && git commit -m "two"

# Revert: riwayat menyimpan kedua commit, plus satu lagi yang membatalkan "two"
git revert --no-edit HEAD
git log --oneline        # 3 commit: revert, two, one

# Reset: pointer branch mundur, "two" lenyap dari log
git reset --hard HEAD~1
git log --oneline        # 1 commit: one

Jalankan keduanya lalu periksa git log — asimetri itulah keseluruhan jawabannya.

Apa sebenarnya yang dilakukan git reset —soft, —mixed, dan —hard?

Ketiga mode mengendalikan di mana perubahan Anda bertahan setelah pointer bergerak:

Mode	Pointer branch	Staging area	Working tree	Suntingan Anda
--soft	mundur	tetap ter-stage	tidak disentuh	utuh semua
--mixed (bawaan)	mundur	tidak ter-stage	tidak disentuh	utuh, tidak ter-stage
--hard	mundur	di-reset	di-reset	terhapus

Cara membaca tabel itu secara konkret:

• git reset --soft HEAD~1 — “Saya commit terlalu dini.” Semuanya kembali ke keadaan ter-stage, siap di-commit ulang, mungkin bersama kerja tambahan.
• git reset HEAD~1 (mixed) — “Saya salah men-stage file.” Suntingan selamat di working tree, tidak ada yang ter-stage. Pasangkan dengan git remove untracked files jika Anda juga ingin file liar ikut hilang.
• git reset --hard HEAD~1 — “Commit ini dan suntingan saya yang belum di-commit adalah sampah.” Git tidak akan bertanya dua kali; tidak ada undo untuk bagian working-tree kecuali Anda menyimpannya lewat stash atau commit lebih dulu.

revert tidak punya mode karena ia tidak pernah menghancurkan apa pun — ia hanya pernah menambah commit kompensasi.

Kapan sebaiknya pakai git revert alih-alih git reset?

Ajukan satu pertanyaan: apakah sudah ada orang lain yang menarik commit ini? Jika ya, reset tereliminasi.

Me-reset branch yang menjadi dasar kerja orang lain berarti menulis ulang riwayat bersama. Pull berikutnya mereka berhadapan dengan branch yang menyimpang, dan “perbaikannya” biasanya force-push yang mengubah kesalahan Anda menjadi masalah semua orang. Revert menambahkan commit biasa, sehingga git pull polos ter-merge bersih untuk semua orang — itulah kenapa revert adalah jawaban baku di main dan di pull request GitHub, tempat tombol “Revert” ada justru karena menulis ulang riwayat PR yang sudah ter-merge bukanlah pilihan.

Reset adalah untuk jendela sebelum dibagikan: commit yang Anda buat tiga puluh detik lalu, kesalahan staging, branch eksperimen lokal. Jika satu-satunya salinan kerja ada di mesin Anda, Anda bebas menata ulang riwayat — itulah seluruh maksud jendela pra-push.

Ada kasus tengah: Anda push ke branch fitur milik sendiri dan tak ada orang lain yang membangun di atasnya. Force-push setelah reset secara sosial masih bisa diterima di sana, tetapi revert tetap lebih murah secara koordinasi. Simpan force-push untuk branch yang Anda miliki sendirian.

Apakah git revert lebih aman dari git reset untuk branch bersama?

Ya, secara struktural — bukan sekadar kebiasaan:

• Revert menghasilkan commit biasa; CI berjalan di atasnya, diff-nya bisa direview, dan git log menjelaskan kepada Anda di masa depan kenapa perubahan itu lenyap.
• Reset membuang keadaan antara secara diam-diam. Tak seorang pun yang me-review belakangan bisa melihat apa yang dibatalkan dan kapan, karena log memperlihatkan garis lurus yang tak pernah memuatnya.

Dua sisi tajam yang praktis:

• Membatalkan merge commit butuh git revert -m 1 <sha> (pertahankan garis parent pertama). Tanpa -m, git menolak dan menyerahkan Anda pada pembacaan pesan error.
• Revert bukan mesin waktu: ia membatalkan diff satu commit. Jika commit berikutnya menyentuh baris yang sama, Anda mungkin perlu menyelesaikan konflik — itu git yang memberi tahu Anda bahwa pembatalannya terjalin, informasi yang berguna, bukan kerusakan.

Untuk membatalkan commit terakhir Anda secara spesifik — mempertahankan atau membuang perubahannya — pilihannya diuraikan di git undo last commit: keep the changes.

Lalu git restore — di mana posisinya?

git restore (bersama git switch, pasangannya) datang di git 2.23 untuk mengambil alih pekerjaan-pekerjaan yang selama ini reset jalani dengan buruk karena kelebihan beban makna:

Tugas	Cara lama	Cara yang jelas
Buang suntingan working-tree di sebuah file	git checkout -- file / git reset --hard	git restore file
Unstage sebuah file	git reset HEAD file	git restore --staged file
Pindahkan branch ke commit lain	git reset <sha>	git reset <sha> (tanpa pengganti — ini tetap)

Jadi pembagian modernnya: restore memperbaiki file, reset memindahkan branch, revert membatalkan commit yang sudah terbit. Autocomplete memperlihatkan orang mencari “git revert vs reset vs restore” sekaligus dengan alasan yang baik — ketiganya satu model mental yang terpecah menjadi tiga perintah. Bentuk git checkout lama tetap bekerja di mana-mana; bentuk baru hanya menghentikan Anda dari mengirim seluruh branch ke penghancur ketika yang Anda maksud hanyalah meng-unstage satu file.

Jika tujuan Anda menyalin commit yang bagus ke depan alih-alih menghapus yang buruk, itu pekerjaan cherry-pick — lihat git cherry-pick: multiple commits, branches, conflicts.

Ringkasan keputusan cepat

1. Commit sudah publik (di-push, ditarik orang lain) → git revert <sha>.
2. Commit hanya lokal, ingin mengulanginya → git reset --soft atau --mixed, lalu commit ulang.
3. Hanya lokal, ingin lenyap beserta kacau-balau yang belum di-commit → git reset --hard, setelah satu kali jujur melihat apa lagi yang dipegang working tree.
4. Satu file rusak → git restore <file> dan biarkan branch-nya sendiri.

Satu-satunya entri yang benar-benar berbahaya dalam daftar itu adalah --hard — sisanya semua bisa dibujak kembali dengan git reflog. Kerugian permanen di git itu sempit dan kebanyakan mengharuskan Anda mengetiknya secara eksplisit; kebiasaan yang layak dibangun adalah berhenti setengah detik sebelum --hard, bukan menghindari alat tajam git sepenuhnya.