switch, restore & checkout: Pindah dan Pulihkan

Kenapa satu perintah dipecah jadi dua?

Dulu, satu perintah git checkout mengerjakan semuanya: pindah branch, mengembalikan file, bahkan membuat branch. Praktis, tapi berbahaya karena satu perintah punya banyak arti. Sejak Git 2.23, tugasnya dipecah agar niatmu eksplisit:

• git switch: HANYA untuk pindah branch, tidak bisa mengutak-atik file.
• git restore: HANYA untuk mengembalikan file, tidak bisa pindah branch.

KENAPA pemisahan ini ada? Supaya perintah yang kamu ketik selalu cocok dengan niat di kepalamu. Niatnya pindah branch tapi malah menimpa file adalah bencana yang seharusnya mustahil terjadi karena salah pilih perintah.

switch: pindah branch dengan aman

git switch fitur-login        # pindah ke branch yang ada
git switch -c fitur-baru      # buat DAN langsung pindah

Contoh 1: ganti konteks di tengah kerja. Kamu lagi ngoding fitur A, tiba-tiba disuruh benerin bug genting:

git switch -c fix/bug-genting

M app.js
Switched to a new branch 'fix/bug-genting'

Perubahan yang belum di-commit ikut terbawa, Git tidak menghapus kerjaanmu diam-diam. KAPAN dipakai? Setiap kali ganti konteks kerja. Kalau Git menolak pindah karena perubahanmu akan tertimpa, itu sinyal untuk commit atau stash dulu, bukan untuk memaksa.

Contoh 2: kembali ke branch semula setelah bug selesai:

git switch fitur-login
# Switched to branch 'fitur-login'

Sederhana, dan karena perintahnya cuma bisa pindah branch, tidak ada risiko file ketimpa.

restore: mengembalikan file ke kondisi terakhir

git restore index.html              # batalkan perubahan BELUM di-staging
git restore --staged index.html     # keluarkan dari staging (editan tetap ada)

Contoh 3: kamu salah edit dan ingin mengulang dari commit terakhir. JANGAN langsung restore, cek dulu apa yang akan dibuang:

git diff index.html
# ... baca dulu perubahannya ...
git restore index.html

KENAPA git diff dulu? Karena git restore menimpa file secara PERMANEN. Yang dibuang tidak masuk riwayat dan tidak bisa dikembalikan, kecuali sempat di-staging atau di-commit. KAPAN dipakai? Untuk dua penyesalan paling umum: "aduh salah edit" dan "aduh ke-add file yang salah".

Contoh 4: kamu tidak sengaja git add file rahasia. Keluarkan dari staging TANPA menghapus editannya:

git restore --staged .env
git status --short

?? .env

File kembali menjadi untracked (tanda ??) dengan isi utuh. KAPAN dipakai? Setiap kali staging salah sasaran, sebelum commit terlanjur dibuat.

checkout: si pisau serbaguna yang sudah pensiun

git checkout adalah perintah lama yang melakukan semua hal di atas sekaligus. Masih banyak tutorial lama yang memakainya, jadi kamu harus bisa MEMBACANYA. Tapi untuk perintah yang kamu ketik sendiri, pakai switch dan restore yang niatnya jelas.

Kesalahan umum pemula: salah vs benar

SALAH: git restore file berharga tanpa cek dulu. Tiga jam kerja hilang permanen, tidak ada undo.

BENAR: selalu intip dulu, baru buang kalau yakin:

git diff app.js        # baca perubahannya
git stash              # atau amankan dulu kalau ragu-ragu

SALAH: pindah branch dengan perubahan penting yang belum di-commit, lalu bingung kenapa perubahan itu "mengikuti" ke branch baru. Itu bukan bug, Git memang membawa perubahan uncommitted saat pindah.

BENAR: commit atau stash dulu sebelum pindah konteks, supaya tiap branch punya kondisi yang jelas.

Detached HEAD: jalan-jalan ke masa lalu

git switch --detach a3f9c1d

Kamu "melayang" di commit lama tanpa branch. Boleh untuk melihat-lihat atau testing, tapi JANGAN commit di sini tanpa membuat branch dulu, karena commit-nya tidak punya pointer dan gampang hilang. Kembali dengan git switch main.