Command Git langka bikin workflow kamu auto lancar

Hei bro & sis calon developer pro!

Pernah ngerasa workflow development pakai Git gitu-gitu aja? add, commit, push, pull, status... Udah kayak menu sehari-hari, tapi kadang ada momen bikin pusing. Misalnya, pas bikin salah commit, atau mau ambil satu commit doang dari branch lain, atau pas lagi ngerjain sesuatu tapi tiba-tiba harus buru-buru pindah branch buat ngecek hotfix. Ribet kan?

Nah, kalau kamu cuma muter-muter di command basic, kamu ibarat punya mobil balap tapi cuma pakai gigi satu. Ada banyak fitur "tersembunyi" di Git yang jarang banget dipakai sehari-hari sama orang kebanyakan, tapi kalau kamu tahu dan bisa pakainya, workflow kamu auto lancar, efisien, dan pastinya nggak gampang panik kalau ada kejadian nggak terduga.

Artikel ini bukan cuma bahas command yang itu-itu lagi ya. Kita bakal bedah command-command "langka" alias jarang dipakai tapi punya superpower buat bikin hidup kamu sebagai developer makin mudah. Siap-siap upgrade skill Git kamu!

1. git reflog: Mesin Waktu Pribadi Kamu

Oke, ini mungkin nggak 100% "langka" banget, tapi banyak junior developer yang nggak tahu betapa powerfull-nya command satu ini. git reflog (Reference Log) itu kayak jurnal pribadi Git kamu. Dia merekam setiap kali HEAD kamu berpindah. Setiap kamu commit, checkout branch lain, reset, merge, rebase, dan operasi lain yang mengubah state repository lokal kamu, reflog mencatatnya.

Kenapa ini superpower? Pernah nggak sengaja pakai git reset --hard ke commit yang salah dan semua perubahan terbaru kamu hilang? Panik mode ON kan? Nah, git reflog adalah penyelamatnya! Dia bisa nunjukkin ke mana aja HEAD kamu pernah "mengunjungi".

Gimana pakenya? Cukup ketik:

bash
git reflog

Kamu bakal lihat daftar aktivitas HEAD kamu, paling baru di atas, lengkap dengan hash commit dan pesan singkat operasinya (misalnya HEAD@{0}: commit: initial commit, HEAD@{1}: moving from master to feature, HEAD@{2}: reset: moving to HEAD~2).

Kalau kamu nggak sengaja reset ke commit yang salah, tinggal lihat di reflog, cari entry sebelum kamu reset, copy hash commit-nya, terus balikin lagi pakai git reset --harddarireflog>. Voila! Perubahan kamu balik lagi. Ini adalah safety net paling ampuh kalau kamu ngaco sama history lokal.

2. git bisect: Detektif Pencari Bug Paling Jago

Bayangin ini: Kemarin code kamu masih jalan normal, hari ini error. Kamu udah bikin puluhan commit dari kemarin sore sampai sekarang. Gimana cara nyari commit mana yang bikin error? Manual satu-satu cek per commit? Bisa gempor!

Di sinilah git bisect berperan. Command ini menggunakan algoritma binary search untuk membantu kamu mencari commit mana yang pertama kali memperkenalkan bug atau perubahan yang tidak diinginkan. Kamu cuma perlu memberi tahu Git mana commit yang "baik" (saat code masih jalan) dan mana commit yang "buruk" (saat bug muncul). Git bakal otomatis checkout ke commit di tengah-tengah rentang itu, kamu cek, terus kasih tahu Git apakah di commit itu code-nya "baik" atau "buruk". Git bakal terus membagi rentang commit sampai akhirnya menemukan commit biang keroknya.

Kenapa ini superpower? Menghemat waktu debugging berkali lipat, terutama di proyek besar dengan history commit yang panjang. Kamu bisa fokus memperbaiki bug setelah tahu pasti di mana dan kapan bug itu muncul.

Gimana pakenya?

1. Mulai proses bisect:

bash
    git bisect start

1. Kasih tahu Git commit mana yang "buruk" (misalnya commit terakhir di branch kamu atau HEAD):

bash
    git bisect bad HEAD

1. Kasih tahu Git commit mana yang "baik" (commit yang kamu yakin code masih benar, bisa pakai hash commit atau tag):

bash
    git bisect good atautagcommityang_baik>

1. Git bakal otomatis checkout ke commit di tengah. Tes code kamu di commit itu.
2. Kasih tahu Git hasilnya:

* Kalau masih bug: git bisect bad * Kalau udah bener: git bisect good

1. Ulangi langkah 4 & 5. Git akan terus narrowing down rentang commit sampai akhirnya bilang "X is the first bad commit".
2. Selesai bisect, jangan lupa reset ke branch awal kamu:

bash
    git bisect reset

Super keren kan? Ini tools wajib tahu buat debugging serius.

3. git cherry-pick: Kurir Pengantar Commit Spesifik

Kadang kamu cuma butuh satu atau dua commit dari satu branch untuk dipindahkan ke branch lain, tanpa harus merge seluruh history branch tersebut. Misalnya, ada hotfix penting di branch develop, dan kamu butuh fix itu di branch fitur kamu yang masih panjang perjalanannya. Merge develop ke branch fitur bisa jadi masalah kalau develop udah jauh banget perubahannya.

git cherry-pick datang sebagai solusi. Command ini memungkinkan kamu mengambil satu commit spesifik dari mana saja di history repository dan menerapkannya sebagai commit baru di branch kamu saat ini.

Kenapa ini superpower? Memberi kamu fleksibilitas tinggi dalam memindahkan perubahan secara selektif. Berguna untuk menerapkan hotfix, membawa perbaikan kecil, atau sekadar mengambil ide dari branch lain tanpa mengganggu struktur branch utama.

Gimana pakenya?

1. Pastikan kamu berada di branch tempat kamu ingin menaruh commit tersebut (git checkout nama-branch-tujuan).
2. Cari hash commit yang ingin kamu ambil (bisa pakai git log di branch sumbernya).
3. Eksekusi cherry-pick:

bash
    git cherry-pick 

Git akan mencoba menerapkan perubahan dari commit tersebut. Kalau ada konflik, selesaikan konfliknya, lalu git add . dan git cherry-pick --continue. Kalau nggak ada konflik, Git akan otomatis membuat commit baru di branch kamu dengan isi yang sama persis.

4. git add -p: Staging Perubahan Secara Selektif (Interactive Staging)

Biasanya kita pakai git add . atau git addbuat masukin perubahan ke staging area. Tapi gimana kalau dalam satu file kamu melakukan banyak perubahan untuk keperluan yang berbeda, dan kamu mau commit perubahan itu secara terpisah? git add . bakal masukin semuanya.

git add -p (atau --patch) memungkinkan kamu meninjau setiap "chunk" (bagian) perubahan dalam file dan memutuskan apakah mau memasukkan chunk itu ke staging area atau tidak.

Kenapa ini superpower? Memberikan kontrol granular atas apa yang masuk ke dalam sebuah commit. Ini membantu kamu membuat commit yang lebih bersih, terfokus, dan logis (atomic commits), yang sangat penting untuk history proyek yang rapi dan proses code review yang lebih mudah.

Gimana pakenya?

bash
git add -p 

Git bakal nunjukin chunk perubahan pertama di file itu dan nanya:

Stage this chunk [y/n/q/a/d/g/e/?]?

Kamu bisa pilih:

• y: Yes, stage this chunk.
• n: No, don't stage this chunk.
• q: Quit, stop staging.
• a: Add all remaining chunks in the file.
• d: Don't add all remaining chunks in the file.
• g: Go to chunk (pilih chunk tertentu).
• e: Edit chunk (edit secara manual chunk mana yang mau distage).
• ?: Show help.

Lanjutin prosesnya sampai semua chunk di file itu ditinjau. Kamu bisa ulangi command ini untuk file lain.

5. git rebase -i: Merapikan History Commit Jadi Kece (Interactive Rebase)

Oke, git rebase dasar mungkin nggak terlalu langka, tapi git rebase -i (interactive rebase) ini beda level. Ini tools buat "menulis ulang" sejarah commit lokal kamu sebelum kamu push atau merge ke branch utama. Kamu bisa menggabungkan (squash) beberapa commit jadi satu, mengedit pesan commit sebelumnya, menghapus commit, atau mengubah urutan commit.

Kenapa ini superpower? Membuat history commit kamu bersih, rapi, dan mudah dibaca. Bayangin kalau kamu punya 10 commit dengan pesan kayak "fix typo", "fix typo lagi", "add button", "oops salah add", "fix button". Dengan interactive rebase, kamu bisa gabungin semua commit "fix typo" dan "fix button" jadi satu atau dua commit yang bermakna, sehingga history-nya jadi "add button" dan "fix button". Ini bikin code review jauh lebih menyenangkan dan history proyek jadi rapi.

Gimana pakenya? Pastikan kamu di branch yang mau dirapikan, lalu tentukan seberapa jauh ke belakang kamu mau rebase. Misalnya, kamu mau rebase 5 commit terakhir:

bash
git rebase -i HEAD~5

Git akan membuka editor dengan daftar 5 commit terakhir dari yang paling tua ke paling baru, dengan instruksi di bawahnya. Setiap baris mewakili satu commit, diawali dengan kata kunci (pick secara default):

pick abcde12 pesan commit 1
pick fghij34 pesan commit 2
pick klmno56 pesan commit 3
pick pqrst78 pesan commit 4
pick uvwxy90 pesan commit 5Rebase abcdefg..uvwxy90 onto abcdefg (5 commands)
# Commands:
p, pick  = use commit
r, reword  = use commit, but edit the commit message
e, edit  = use commit, but stop for amending
s, squash  = use commit, but meld into previous commit
f, fixup  = like "squash", but discard this commit's log message
x, exec  = run command (the rest of the line) using shell
d, drop  = discard commit
l, label  = label current HEAD with a name
t, Tanner (old name for label)
m, merge  [] = merge the branch pointed to by  onto the current branch

Edit kata kunci di depan hash commit sesuai yang kamu mau. Contoh, mau gabungin commit 2, 3, 4 ke commit 1, dan edit pesan commit 5:

pick abcde12 pesan commit 1
squash fghij34 pesan commit 2
squash klmno56 pesan commit 3
squash pqrst78 pesan commit 4
reword uvwxy90 pesan commit 5

Save dan tutup editor. Git akan menjalankan perintahnya. Kalau ada squash, Git akan membuka editor baru untuk menggabungkan pesan commit. Kalau ada reword, Git akan membuka editor untuk mengedit pesan commit itu.

CATATAN PENTING: Jangan pernah melakukan interactive rebase (atau rebase dalam bentuk apa pun) pada commit yang SUDAH kamu push ke remote repository yang dipakai orang lain. Ini akan menulis ulang sejarah dan bisa bikin konflik parah di tim kamu. Gunakan ini hanya untuk merapikan commit-commit lokal sebelum dipush atau dibuat Pull Request.

6. git stash: Mengelola Perubahan yang Belum Siap (Advanced Stashing)

Kamu mungkin udah tahu git stash buat nyimpen perubahan sementara pas mau pindah branch. Tapi tahukah kamu ada opsi-opsi lain yang bikin stashing lebih powerful?

Kenapa ini superpower? Memungkinkan kamu mengelola beberapa set perubahan yang belum siap di commit, tanpa harus membuat commit sementara yang nggak jelas. Berguna banget saat kamu harus sering pindah konteks kerja.

Gimana pakenya?

• git stash push -m "Pesan Stash": Nyimpen perubahan (termasuk file yang di-tracked tapi belum distage) dengan pesan biar gampang inget. Mirip git stash save "Pesan".
• git stash list: Melihat daftar semua stash yang tersimpan. Outputnya kayak gini: stash@{0}: On feature/kerjaan-a: Pesan Stash, stash@{1}: WIP on master: ....
• git stash show stash@{n}: Melihat detail perubahan di stash tertentu (ganti n dengan nomor stash dari stash list). Tambahin -p buat lihat diff-nya: git stash show -p stash@{n}.

git stash apply stash@{n}: Menerapkan stash tanpa* menghapusnya dari daftar stash. Berguna kalau kamu mau menerapkan stash yang sama di beberapa tempat atau jaga-jaga kalau penerapan stash gagal. git stash pop stash@{n}: Menerapkan stash dan* menghapusnya dari daftar stash. Ini perilaku default kalau kamu cuma pakai git stash pop (dia akan pop yang paling baru, stash@{0}).

• git stash drop stash@{n}: Menghapus stash tertentu dari daftar.
• git stash clear: Menghapus semua stash dari daftar. Hati-hati pakai ini!

Dengan variasi ini, kamu nggak cuma bisa nyimpen satu set perubahan, tapi bisa punya beberapa stash aktif untuk kebutuhan yang beda-beda.

7. git worktree: Buka Proyek yang Sama di Beberapa Branch Sekaligus

Ini command yang mungkin paling jarang ditemui, tapi super berguna di skenario tertentu. Pernah nggak kamu lagi asik kerja di branch feature-A, terus tiba-tiba dikasih tugas mendadak buat cek atau ngerjain sesuatu di bugfix-B yang based-nya beda jauh, atau malah di branch master buat hotfix? Biasanya kan kita harus git stash dulu, git checkout, beres kerja, git checkout balik, git stash apply. Ribet dan rawan konflik.

git worktree memungkinkan kamu membuat working directory baru yang terhubung ke repository yang sama, tapi checkout di branch atau commit yang berbeda. Jadi, kamu bisa punya dua (atau lebih) folder proyek yang isinya branch berbeda, dan kamu bisa pindah-pindah antar folder itu tanpa perlu stashing atau checkout di dalam satu folder.

Kenapa ini superpower? Memungkinkan paralelisme dalam workflow. Kamu bisa ngerjain feature sambil ngecek rilis di branch lain, atau nge-test branch lama, tanpa mengganggu satu sama lain. Setiap worktree punya status Git sendiri.

Gimana pakenya? Misalnya kamu lagi di folder my-project di branch feature-A. Kamu mau bikin working directory baru di folder ../my-project-bugfix untuk branch bugfix-B.

bash
cd my-project # Pastikan kamu di root repo utama
git worktree add ../my-project-bugfix bugfix-B

Git akan membuat folder ../my-project-bugfix dan otomatis checkout branch bugfix-B di sana. Sekarang kamu punya dua folder:

• my-project/: Repo utama, di branch feature-A.
• my-project-bugfix/: Worktree baru, di branch bugfix-B.

Kamu bisa kerja di kedua folder itu secara independen. Untuk melihat daftar worktree yang aktif:

bash
git worktree list

Untuk menghapus worktree (pastikan kamu tidak sedang berada di dalamnya):

bash
git worktree remove ../my-project-bugfix

Kalau branch-nya udah di-merged atau nggak dibutuhkan lagi, kamu bisa pakai -f atau hapus branch-nya setelah remove worktree.

8. git clean: Bersihin File Nggak Penting yang Nggak Di-Track

Kadang proyek kamu jadi kotor sama file-file yang nggak di-track sama Git. Bisa hasil compile, file log, file temporer, atau file iseng yang kamu buat buat ngetes sesuatu. File-file ini muncul pas kamu git status, bikin output-nya rame dan kadang bikin bingung.

git clean adalah command buat menghapus file-file yang nggak di-track ini dari working directory kamu.

Kenapa ini superpower? Menjaga working directory kamu tetap bersih dan rapi. Ini penting sebelum melakukan operasi Git tertentu (seperti switching branches secara agresif) atau sekadar memastikan environment kamu bersih.

Gimana pakenya? SUPER HATI-HATI PAKAI COMMAND INI! File yang dihapus pakai git clean TIDAK BISA dikembalikan. Selalu lakukan dry run dulu.

1. Dry Run (Lihat apa yang akan dihapus):

bash
    git clean -n

Git akan menampilkan daftar file yang akan dihapus. Baca baik-baik daftarnya, pastikan nggak ada file penting di situ.

1. Hapus File: Kalau sudah yakin, jalankan command ini:

bash
    git clean -f

Ini akan menghapus file yang nggak di-track.

1. Hapus File DAN Direktori: Kalau ada folder kosong atau folder hasil build yang juga nggak di-track dan mau dihapus:

bash
    git clean -fd

(-d untuk menyertakan direktori)

1. Hapus File, Direktori, DAN File yang Di-Ignore: Kalau kamu mau "super bersih" termasuk file yang sebenarnya udah kamu masukin .gitignore (jarang banget sih, tapi bisa):

bash
    git clean -fxd

(-x untuk menyertakan file yang di-ignore)

Ingat, selalu pakai -n dulu ya!

9. git alias: Bikin Shortcut Command Git Kamu Sendiri

Command Git itu banyak dan kadang panjang. git status, git checkout, git commit -am "...". Kalau sering ngetik command yang sama, jari bisa keriting. Git punya fitur alias yang memungkinkan kamu bikin shortcut sendiri.

Kenapa ini superpower? Meningkatkan kecepatan dan efisiensi kamu saat berinteraksi dengan Git. Customisasi ini bikin workflow kamu jadi lebih personal dan cepat.

Gimana pakenya? Kamu bisa bikin alias lewat command line:

bash
git config --global alias.st status
git config --global alias.co checkout
git config --global alias.ci commit
git config --global alias.br branch
git config --global alias.commend "commit --amend --no-edit" # Contoh shortcut yg lebih kompleks

Setelah ini, kamu bisa pakai git st daripada git status, git co daripada git checkout, git ci daripada git commit, dan seterusnya. Alias ini disimpan di file konfigurasi global Git kamu (~/.gitconfig). Kamu bisa buka file itu pakai editor teks dan lihat daftar alias yang udah dibuat.

Tips Tambahan Buat Command Langka Ini:

• Latihan di Repo Dummy: Jangan coba command "langka" (terutama yang bisa merusak history kayak rebase -i atau yang menghapus file kayak clean -f) langsung di proyek penting. Bikin repo dummy atau clone proyek kamu ke folder terpisah dan latihan di sana.
• Baca Dokumentasi: Setiap command Git punya dokumentasi lengkap yang bisa diakses pakai man git(misal: man git reflog, man git bisect). Ini sumber ilmu paling akurat.
• Pahami Konsekuensinya: Terutama command yang mengubah history (rebase -i, commit --amend) atau menghapus file (clean). Pastikan kamu tahu apa yang terjadi sebelum eksekusi.
• Gabungkan dengan Command Dasar: Command langka ini paling powerfull kalau digabungkan dengan command dasar. Misalnya, pakai git log buat nyari hash commit buat cherry-pick atau bisect.

Penutup

Git itu lebih dari sekadar add, commit, push, pull. Ada banyak tools canggih di dalamnya yang sengaja disediain buat bikin hidup developer lebih gampang. Command-command "langka" kayak reflog, bisect, cherry-pick, add -p, rebase -i, stash dengan variasinya, worktree, clean, dan alias mungkin nggak kamu pakai setiap hari, tapi pas kamu butuh, mereka bisa jadi penyelamat waktu dan bikin workflow kamu auto lancar.

Jangan takut buat eksplorasi dan nyoba command-command baru. Semakin banyak tools yang kamu kuasai, semakin efisien dan percaya diri kamu ngoding pakai Git. Selamat mencoba dan jadi master Git sejati!