Panduan Untuk Menghapus Kesalahan Dengan Git (Bagian 2)

Di bagian kedua dari seri kami tentang "Mengurungkan Kesalahan dengan Git", kami akan dengan berani melihat bahaya di mata lagi: Saya telah menyiapkan empat skenario hari kiamat baru — termasuk, tentu saja, beberapa cara cerdas untuk menyelamatkan leher kita! Tetapi sebelum kita masuk lebih dalam: lihat artikel sebelumnya di Git untuk mengetahui lebih banyak metode penyelamatan diri yang membantu Anda memperbaiki kesalahan Anda dengan Git!

Ayo pergi!

Memulihkan Cabang yang Dihapus Menggunakan Reflog

Pernahkah Anda menghapus cabang dan, segera setelah itu, menyadari bahwa Anda seharusnya tidak menghapusnya? Jika Anda tidak tahu perasaan ini, saya dapat memberitahu Anda bahwa itu bukan perasaan yang baik. Campuran kesedihan dan kemarahan merayapi Anda, sementara Anda memikirkan semua kerja keras yang dilakukan untuk komitmen cabang itu, semua kode berharga yang sekarang telah Anda hilangkan.

Untungnya, ada cara untuk menghidupkan kembali cabang itu dari kematian — dengan bantuan alat Git bernama “Reflog”. Kami telah menggunakan alat ini di bagian pertama dari seri kami, tapi ini sedikit penyegaran: Reflog seperti jurnal di mana Git mencatat setiap gerakan penunjuk HEAD di repositori lokal Anda. Dengan kata lain yang tidak terlalu aneh: setiap kali Anda checkout, komit, gabungkan, rebase, cherry-pick, dan seterusnya, entri jurnal dibuat. Ini menjadikan Reflog sebagai jaring pengaman yang sempurna saat terjadi kesalahan!

Mari kita lihat contoh konkritnya:

 $ git branch * feature/login master

Kami dapat melihat bahwa kami saat ini telah memeriksa feature/login kami. Katakanlah ini adalah cabang yang akan kita hapus (secara tidak sengaja). Namun, sebelum kita dapat melakukannya, kita perlu beralih ke cabang lain karena kita tidak dapat menghapus cabang HEAD kita saat ini!

 $ git checkout master $ git branch -d feature/login

Cabang fitur berharga kami sekarang hilang — dan saya akan memberi Anda waktu sebentar untuk (a) memahami beratnya kesalahan kami dan (b) sedikit berduka. Setelah Anda menghapus air mata, kita perlu menemukan cara untuk mengembalikan cabang ini! Mari kita buka Reflog (cukup dengan mengetik git reflog ) dan lihat apa yang tersedia untuk kita:

Berikut adalah beberapa komentar untuk membantu Anda memahami output:

• Pertama-tama, Anda perlu tahu bahwa Reflog mengurutkan entrinya secara kronologis: item terbaru ada di bagian atas daftar.
• Item paling atas (dan karenanya terbaru) adalah perintah git checkout yang kami lakukan sebelum menghapus cabang. Itu dicatat di sini di Reflog karena ini adalah salah satu dari "gerakan penunjuk KEPALA" yang dicatat oleh Reflog dengan patuh.
• Untuk membatalkan kesalahan besar kita, kita cukup kembali ke keadaan sebelumnya — yang juga tercatat dengan bersih dan jelas di Reflog!

Jadi mari kita coba ini, dengan membuat cabang baru (dengan nama cabang "hilang" kita) yang dimulai pada hash SHA-1 status "sebelum" ini:

 $ git branch feature/login 776f8ca

Dan voila! Anda akan senang melihat bahwa kami sekarang telah memulihkan cabang kami yang tampaknya hilang!

Jika Anda menggunakan GUI desktop Git seperti "Tower", Anda dapat mengambil jalan pintas yang bagus: cukup tekan CMD + Z pada keyboard Anda untuk membatalkan perintah terakhir — bahkan jika Anda baru saja menghapus cabang dengan kasar!

Memindahkan Komitmen ke Cabang yang Berbeda

Di banyak tim, ada kesepakatan untuk tidak melakukan commit pada cabang yang sudah berjalan lama seperti main atau develop : cabang seperti ini seharusnya hanya menerima commit baru melalui integrasi (mis. penggabungan atau rebase). Namun, tentu saja, kesalahan tidak dapat dihindari: kita terkadang lupa dan berkomitmen pada cabang-cabang ini! Jadi bagaimana kita bisa membersihkan kekacauan yang kita buat?

Untungnya, jenis masalah ini dapat dengan mudah diperbaiki. Mari menyingsingkan lengan baju dan mulai bekerja.

Langkah pertama adalah beralih ke cabang tujuan yang benar dan kemudian memindahkan komit secara berlebihan menggunakan perintah cherry-pick :

 $ git checkout feature/login $ git cherry-pick 776f8caf

Anda sekarang akan memiliki komit di cabang yang diinginkan, di mana seharusnya di tempat pertama. Luar biasa!

Tapi masih ada satu hal yang harus dilakukan: kita harus membersihkan cabang tempat ia mendarat secara tidak sengaja ! Perintah cherry-pick , bisa dikatakan, membuat salinan komit — tetapi yang asli masih ada di cabang kami yang sudah berjalan lama:

Ini berarti kita harus beralih kembali ke cabang lama kita dan menggunakan git reset untuk menghapusnya:

 $ git checkout main $ git reset --hard HEAD~1

Seperti yang Anda lihat, kami menggunakan perintah git reset di sini untuk menghapus komit yang salah. Parameter HEAD~1 memberi tahu Git untuk "mengembalikan 1 revisi di belakang HEAD", secara efektif menghapus komit paling atas (dan dalam kasus kami: tidak diinginkan) dari riwayat cabang itu.

Dan voila: komit sekarang berada di tempat yang seharusnya dan cabang kami yang sudah berjalan lama bersih — seolah-olah kesalahan kami tidak pernah terjadi!

Mengedit Pesan dari Komitmen Lama

Terlalu mudah untuk menyelundupkan kesalahan ketik ke dalam pesan komit — dan baru akan menemukannya nanti. Dalam kasus seperti itu, opsi --amend lama yang bagus dari git commit tidak dapat digunakan untuk memperbaiki masalah ini, karena ini hanya berfungsi untuk komit terakhir. Untuk memperbaiki komit yang lebih lama dari itu, kita harus menggunakan alat Git yang disebut "Interactive Rebase".

Pertama, kita harus memberi tahu Interactive Rebase bagian mana dari riwayat komit yang ingin kita edit. Ini dilakukan dengan memberinya hash komit: komit induk dari yang ingin kita manipulasi.

 $ git rebase -i 6bcf266b

Jendela editor kemudian akan terbuka. Ini berisi daftar semua komit setelah yang kami berikan sebagai dasar untuk Rebase Interaktif dalam perintah:

Di sini, penting agar Anda tidak mengikuti dorongan pertama Anda: pada langkah ini, kami belum mengedit pesan komit. Sebagai gantinya, kami hanya memberi tahu Git jenis manipulasi apa yang ingin kami lakukan dengan komit mana. Cukup nyaman, ada daftar kata kunci tindakan yang dicatat di komentar di bagian bawah jendela ini. Untuk kasus kami, kami menandai baris #1 dengan reword (dengan demikian menggantikan pick standar).

Yang tersisa untuk dilakukan dalam langkah ini adalah menyimpan dan menutup jendela editor. Sebagai gantinya, jendela editor baru akan terbuka yang berisi pesan saat ini dari komit yang kami tandai. Dan sekarang saatnya untuk melakukan pengeditan!

Berikut sekilas seluruh proses untuk Anda:

Memperbaiki Komitmen yang Rusak (dengan Cara yang Sangat Elegan)

Akhirnya, kita akan melihat fixup , Pisau Tentara Swiss untuk melepas alat. Sederhananya, ini memungkinkan Anda untuk memperbaiki komit yang rusak/tidak lengkap/salah setelah fakta. Ini benar-benar alat yang luar biasa karena dua alasan:

1. Tidak peduli apa masalahnya.
   Anda mungkin lupa menambahkan file, seharusnya menghapus sesuatu, membuat perubahan yang salah, atau hanya salah ketik. fixup berfungsi di semua situasi ini!
2. Ini sangat elegan.
   Reaksi normal dan naluriah kami terhadap bug dalam komit adalah menghasilkan komit baru yang memperbaiki masalah. Cara kerja ini, betapapun intuitifnya kelihatannya, membuat riwayat komit Anda terlihat sangat kacau, segera. Anda memiliki komit "asli" dan kemudian komit "perban" kecil ini yang memperbaiki hal-hal yang salah dalam komit asli. Riwayat Anda dipenuhi dengan komitmen bantuan pita kecil yang tidak berarti yang membuat sulit untuk memahami apa yang terjadi di basis kode Anda.

Di sinilah fixup masuk. Ini memungkinkan Anda untuk tetap membuat komit perbaikan pita ini. Tapi inilah keajaibannya: itu kemudian menerapkannya ke komit asli yang rusak (memperbaikinya seperti itu) dan kemudian membuang komit bantuan-band jelek sepenuhnya!

Kita bisa melalui contoh praktis bersama-sama! Katakanlah komit yang dipilih di sini rusak.

Katakan juga bahwa saya telah menyiapkan perubahan dalam file bernama error.html yang akan menyelesaikan masalah. Inilah langkah pertama yang perlu kita lakukan:

 $ git add error.html $ git commit --fixup 2b504bee

Kami sedang membuat komit baru, tetapi kami memberi tahu Git bahwa ini adalah komit khusus: ini adalah perbaikan untuk komit lama dengan hash SHA-1 yang ditentukan ( 2b504bee dalam kasus ini).

Langkah kedua, sekarang, adalah memulai sesi Interactive Rebase — karena fixup termasuk dalam perangkat besar Interactive Rebase.

 $ git rebase -i --autosquash 0023cddd

Ada dua hal yang perlu dijelaskan tentang perintah ini. Pertama, mengapa saya memberikan 0023cddd sebagai hash revisi di sini? Karena kita perlu memulai sesi Rebase Interaktif kita di komit induk rekan kita yang rusak.

Kedua, untuk apa opsi --autosquash ? Dibutuhkan banyak pekerjaan dari bahu kita! Di jendela editor yang sekarang terbuka, semuanya sudah disiapkan untuk kita:

Berkat opsi --autosquash , Git telah melakukan pekerjaan berat untuk kami:

1. Itu menandai komitmen bantuan pita kecil kami dengan kata kunci tindakan fixup . Dengan begitu, Git akan menggabungkannya dengan komit langsung di atas dan kemudian membuangnya.
2. Itu juga menyusun ulang baris yang sesuai, memindahkan komit bantuan pita kami langsung di bawah komit yang ingin kami perbaiki (sekali lagi: fixup bekerja dengan menggabungkan komit yang ditandai dengan yang di atas !).

Singkatnya: Tidak ada yang bisa kita lakukan selain menutup jendela!

Mari kita lihat hasil akhirnya.

• Komit yang sebelumnya rusak telah diperbaiki: sekarang berisi perubahan yang kami siapkan di komit bantuan pita kami.
• Komit plester yang jelek itu sendiri telah dibuang: riwayat komit bersih dan mudah dibaca — seolah-olah tidak ada kesalahan yang terjadi sama sekali.

Mengetahui Cara Mengurungkan Kesalahan adalah Kekuatan Super

Selamat! Anda sekarang dapat menyelamatkan leher Anda dalam banyak situasi sulit! Kami tidak dapat benar-benar menghindari situasi ini: tidak peduli seberapa berpengalaman kami sebagai pengembang, kesalahan hanyalah bagian dari pekerjaan. Tetapi sekarang setelah Anda tahu cara menghadapinya, Anda dapat menghadapinya dengan detak jantung yang santai.

Jika Anda ingin mempelajari lebih lanjut tentang memperbaiki kesalahan dengan Git, saya dapat merekomendasikan "First Aid Kit for Git" gratis, serangkaian video pendek tentang topik ini.

Bersenang-senang membuat kesalahan — dan, tentu saja, membatalkannya dengan mudah!