Ada perubahan yang lulus semakan tetapi menimbulkan masalah sebaik sahaja dideploy. Dalam keadaan cemas, kita mungkin teringat git reset --hard dan mahu menolak sejarah baharu secepat mungkin. Bagi branch yang sudah digunakan orang lain, langkah itu boleh menambah kekeliruan.
Cari commit yang hendak dibatalkan
Lihat git log --oneline dan pastikan commit tersebut memang punca masalah. Semak juga sama ada perubahan lain bergantung padanya. Jika satu commit yang jelas perlu diundur, git revert <hash> menghasilkan commit baharu yang membalikkan perubahan terdahulu. Sejarah asal masih boleh dibaca, dan rakan pasukan boleh menarik perubahan seperti biasa. Manual Git menerangkan tingkah laku arahan ini serta pilihan untuk konflik.
Jika revert bertembung dengan kod yang berubah selepas commit tersebut, baca konflik satu persatu. Jangan pilih seluruh bahagian “ours” atau “theirs” secara automatik. Uji aliran yang rosak dan aliran yang berdekatan sebelum push. Bagi perubahan pangkalan data atau fail yang telah diproses pengguna, revert kod sahaja mungkin tidak cukup; sediakan langkah pemulihan data yang berasingan.
Selepas revert, semak juga sama ada perubahan asal mempunyai kesan di luar repository. Contohnya, e-mel mungkin sudah dihantar atau migrasi data sudah dijalankan. Commit pembalik tidak boleh menarik balik perkara tersebut secara automatik. Senarai kesan sampingan ini patut berada dalam nota insiden sebelum pasukan menganggap masalah selesai.
Selepas keadaan stabil, tulis nota ringkas tentang punca dan cara mengesan masalah lebih awal. Tujuan revert bukan mencari salah siapa. Ia alat untuk memulihkan perkhidmatan sambil memberi pasukan masa untuk membuat pembetulan yang lebih teliti.