Bagian 2: Memulihkan Commit

Bencana pertama datang dari satu perintah yang terlihat biasa. Bayangkan pagi yang tadi begitu rapi berakhir dengan keputusan yang keliru: percaya bahwa dua commit terakhir salah arah, kita menjalankan git reset --hard HEAD~2 — dan Git mematuhinya tanpa bertanya. Dalam sekejap, log menyusut dari lima commit menjadi tiga, isi berkas ikut mundur, dan terminal tidak menyisakan satu petunjuk pun. Bagian ini memutar ulang detik-detik itu dengan tenang, lalu membuktikan bahwa bencana tersebut bisa dibatalkan total lewat reflog.

Bencana Pertama: reset –hard HEAD~2 #

Perintah ini memindahkan main dua commit ke belakang dan menulis ulang working tree mengikuti posisi baru — perilaku ketiga modus reset yang dibedah di Reset Soft, Mixed, dan Hard . Jalankan seperti orang yang yakin sedang melakukan hal benar:

git reset --hard HEAD~2

Output yang Dihasilkan:

HEAD is now at 1c4a93c Tambah resep rendang

Satu baris itu seluruh kabar yang diberikan Git. Kelihatannya rapi — padahal baris itu mengumumkan bahwa catatan penyajian dan daftar resep baru saja lenyap dari pandangan.

Panik yang Tertata: Log Hanya Tiga Commit #

Inilah momen ketika kebanyakan orang mulai berkeringat. Periksa riwayat:

git log --oneline

Output yang Dihasilkan:

1c4a93c Tambah resep rendang
691f4f6 Tambah resep gudeg
12594d0 Rintis buku resep dengan resep sup

Lima menjadi tiga. Dua commit terakhir — 84e2ae5 Tambah catatan penyajian dan 563d368 Lengkapi README dengan daftar resep — tidak lagi muncul. Yang lebih mengerikan: keadaannya terlihat sehat:

git status

Output yang Dihasilkan:

On branch main
nothing to commit, working tree clean

Tidak ada berkas hilang, tidak ada peringatan, tidak ada tombol undo yang ditawarkan. Working tree bersih karena --hard ikut memundurkan isinya — catatan penyajian sungguh tidak ada lagi di sample.txt.

Simulasi paniknya sampai di sini. Dua hal yang perlu diingat persis pada situasi sungguhan: pertama, berhenti dan jangan menjalankan git gc, git prune, atau git reflog expire — pembersihan seperti itu menghapus objek yang statusnya “hilang”, sebagaimana ditegaskan di Prosedur Recovery Aman . Kedua, ingat pelajaran Bagian 1: HEAD mencatat perjalanannya sendiri.

Menemukan Commit yang Hilang #

Buka peta pergerakan:

git reflog

Output yang Dihasilkan:

1c4a93c HEAD@{0}: reset: moving to HEAD~2
563d368 HEAD@{1}: commit: Lengkapi README dengan daftar resep
84e2ae5 HEAD@{2}: commit: Tambah catatan penyajian
1c4a93c HEAD@{3}: commit: Tambah resep rendang
691f4f6 HEAD@{4}: commit: Tambah resep gudeg
12594d0 HEAD@{5}: commit (initial): Rintis buku resep dengan resep sup

Enam baris — satu lebih banyak dari jumlah commit. Mari baca seperti investigator:

1. HEAD@{0} adalah kejadian itu sendiri — reset: moving to HEAD~2 mencatat perpindahan ke 1c4a93c, persis baris yang barusan kita jalankan.
2. HEAD@{1} adalah keadaan sebelum bencana — commit 563d368 “Lengkapi README dengan daftar resep” adalah posisi HEAD tepat sebelum reset; itulah alamat yang “hilang”.
3. Dua commit yang lenyap dari log masih tercatat utuh — 563d368 dan 84e2ae5 berdiri di HEAD@{1} dan HEAD@{2}, dengan isi blob yang masih tersimpan di database objek.

Kesimpulannya menenangkan: reset hanya memindahkan penunjuk main; kedua commit tetap hidup, hanya kehilangan jalanan menuju mereka. Teori lengkapnya dibahas di Memulihkan Commit .

Memulihkan main #

Uraikan dulu alamatnya menjadi hash penuh — langkah kecil yang memastikan kita menunjuk benda yang benar sebelum menyentuh apa pun:

git rev-parse HEAD@{1}

Output yang Dihasilkan:

563d368f9cb39a5543dee7b50dfe277004449483

Hash itu adalah commit ke-lima kita. Pulihkan main dengan mengarahkan reset — perintah yang sama yang tadi jadi bencana, kini jadi obat:

git reset --hard 563d368f9cb39a5543dee7b50dfe277004449483

Output yang Dihasilkan:

HEAD is now at 563d368 Lengkapi README dengan daftar resep

Periksa hasilnya dua lapis. Riwayat:

git log --oneline

Output yang Dihasilkan:

563d368 Lengkapi README dengan daftar resep
84e2ae5 Tambah catatan penyajian
1c4a93c Tambah resep rendang
691f4f6 Tambah resep gudeg
12594d0 Rintis buku resep dengan resep sup

Lima commit kembali lengkap. Isi berkasnya ikut kembali — ujung sample.txt yang barusan hilang:

tail -n 5 sample.txt

Output yang Dihasilkan:

## Catatan Penyajian

Sajikan sup jagung hangat, gudeg dengan nasi putih, dan rendang
paling pas dalam keadaan kering.

Pemulihan tuntas: penunjuk, riwayat, dan isi working tree kembali ke keadaan sebelum bencana, baris demi baris.

Dua Jalur, Satu Keputusan #

Jalur yang barusan kita pakai — git reset --hard <hash> — memutar waktu ke belakang: main kembali persis ke posisi pra-bencana. Git menyediakan jalur kedua yang resmi:

git branch pulihan 563d368f9cb39a5543dee7b50dfe277004449483
git merge pulihan

Perintah pertama menancapkan branch baru pulihan pada commit yang hilang, perintah kedua menggabungkannya. Keduanya sama-sama mengembalikan pekerjaan — pembedanya adalah situasi: bila main sudah berisi kerja baru setelah bencana, reset akan menimpanya, sedangkan jalur branch membiarkan keduanya berdamai lewat merge. Perbandingan kedua jalur ini dirinci di Memulihkan Commit ; dokumentasi perilaku git reset tersedia di git-reset .

Pelajaran: reset Bukan Hapus #

Bencana pertama ditutup dengan satu kalimat yang layak dihafal: git reset memindahkan penunjuk, bukan menghapus commit. Commit yang “lenyap” tetap berdiri di database objek selama reflog masih mencatat alamatnya — dan pembersih git gc tidak akan menyentuhnya selama alamat itu hidup. Hari buruk kita belum selesai: bencana berikutnya lebih besar lagi, satu branch utuh dengan dua commit dihapus paksa — dan reflog HEAD yang menyimpan alamatnya: Bagian 3: Memulihkan Branch .