Git Stash — An Overlooked Feature

Benny William Pardede
PPL D7 — Fasilkom UI
4 min readMar 18, 2019
Photo by Jan Antonin Kolar 🇨🇿 on Unsplash

Tidak diragukan lagi bahwa banyak komunitas dalam industri pengembangan perangkat lunak menggunakan Git sebagai alat bantu version control software mereka. Bagaimana tidak, software ini sangat membantu dalam kerja tim sebagai perekam progress dari kode sumber yang dikerjakan. Setiap orang bisa menyimpan (commit) progress pekerjaannya dan membukanya kembali di PC yang berbeda (push-pull). Setiap anggota tim bisa membuat branch masing-masing agar tidak menggangu pekerjaan anggota lain. Dan kalaupun terjadi ‘bentrok’ pada branch yang ingin digabungkan (merge), git memiliki fitur pengingat (conflict) yang memudahkan developer melacak tulisan yang bentrok. Perekaman state yang bisa dibatalkan (revert) memudahkan pengembang untuk keluar dari state perangkat lunak yang cacat dan kembali ke state yang benar.

Fitur-fitur yang sudah disebutkan di atas merupakan fitur-fitur mainstream yang sudah biasa dipakai oleh pengguna Git. Namun ada satu fitur lagi yang sangat berguna namun sering dipandang sebelah mata karena kegunaannya yang sepele. Menurut saya fitur ini wajib dipahami oleh kalian para pengembang software yang bekerja sendiri maupun berkelompok.

Namanya adalah stash, atau di command line ditulis dengan git stash. Fitur stash ini berperan untuk menyimpan semua progress yang sudah kamu lakukan sejak commit terakhir tanpa membuat sebuah commit untuk state itu sendiri.

Bukannya makin sering commit makin bagus ya? Kok saya dihalang-halangin buat commit? Kan ‘mayan udah ada progress.

Perlu kamu ketahui bahwa tidak semua komunitas/perusahaan pengembangan software membolehkan kamu untuk meng-commit sesuatu yang implementasinya setengah jadi. Walau tidak banyak, ada komunitas yang mengevaluasi pekerjaan anggota tim dengan melihat konten dari commit-commit tiap anggota.

Ya saya tidak bekerja dengan orang-orang seperti itu, terus apa fitur stash masih berguna?

Bayangkan situasi seperti ini: Kamu sedang implementasi fitur baru, kamu sudah ngoding cukup lama dan belum commit-commit juga karena memang fungsi yang kamu bikin belum bisa running juga. Tiba-tiba datanglah bos yang memberi kabar darurat bahwa implementasi kamu yang di-release kemarin malam memiliki bug fatal dan harus diperbaiki segera.

Kamu gamau progress kamu sejauh ini hilang begitu saja. Tapi kamu pasti harus ganti ke branch lain karena bugnya berada di branch master (misal). Tapi kamu harus commit dulu karena git akan membawa semua file yang kamu edit saat checkout ke branch itu. Tapi kamu juga tidak boleh commit karena implementasi belum selesai. Tapi kamu tidak-

Yang bisa kamu lakukan untuk menghindari commit adalah men-stash semua progress kamu sejauh ini ke dalam stack stash milik git. Nanti setelah kamu selesai fix bug, kamu bisa kembali ke branch sebelumnya dan mengembalikan progress kamu dari stack.

Gimana tuh langkah-langkahnya?

$ git stash
yaudah gitu aja. Nanti git bakal menyimpan semua progress yang kamu buat semenjak commit terakhir ke dalam sebuah stack yang berisi semua stash yang pernah kamu lakukan. Setelah selesai stash, file-file yang dilacak oleh git, baik yang masuk ke stage atau belum masuk stage, akan kembali ke state semenjak commit paling terakhir. Untuk melihat stash-stash yang pernah kamu simpan, cukup jalankan perintah
$ git stash list

$ git stash list
stash@{0}: WIP on pointbr: 129d0b8 Revise Deckorfile
stash@{1}: WIP on stage: g26205f Revert "Added package.zip"
stash@{2}: WIP on devve2: 52ds0a5 Add function SomethingGood

WIP artinya Work In Progress, “on qwerty” artinya kamu nge-stash progress pada branch “qwerty”, dibantu Git biar gak lupa. Sisanya adalah ID commit dan pesan commit terakhir di branch “qwerty” saat kamu menjalankan git stash. Ingat bahwa urutan dari daftar stash tersebut bersifat stack. Stash paling atas adalah stash yang paling terakhir kamu push ke daftar. Jika kamu push lagi stash baru, id stash tersebut akan menjadi stash@{0}.

Udah kelar hotfix-nya, mau balikin kerjaanku gimana

Jika ceritanya kamu sudah selesai memperbaiki urusanmu di branch lain, seperti pada cerita hotfix tadi, kamu checkout kembali ke branch semula lalu mengembalikan progress yang kamu simpan dalam stash tadi. Caranya adalah dengan perintah
$ git stash apply/pop [<stash>]
Bedanya apply dengan pop adalah jika kamu menggunakan apply, stash yang baru saja di-restore tidak akan dihapus dari stack, sementara stash akan hilang jika kamu menggunakan perintah pop.
Argumen [<stash>] diisi dengan nomor identitas stash pada stack yang ditunjukkan pada stash list di atas. Format penulisan ID stash mengikuti apa yang dituliskan pada output stash list, misal $ git stash apply/pop stash@{1}. Jika tidak diberi argumen, git akan menggunakan stash default dari paling atas stack: stash@{0}.

Aku lupa progress apa aja yang aku save di tiap stash

Kamu cukup menggunakan perintah $ git stash show [<stash>] . Seperti apply/pop, argumen [<stash>] diisi dengan ID stash yang ingin ditunjukkan. Nanti akan dipaparkan oleh git apa saja progress yang kamu simpan pada stash tersebut.

Cukup mudah bukan? Git stash cocok menjadi alternatif buat kalian yang memiliki batasan-batasan tertentu untuk melakukan sebuah git commit tanpa harus menghapus progress kalian. Oh iya, melakukan git apply/pop tidak menutup kemungkinan untuk memicu merge conflict setelah mengembalikan state progress. Rollback yang tidak bersih memicu merge conflict yang harus diselesaikan sendiri. Jadi jangan lupa untuk cek isi stash (git stash show) sebelum apply kembali ya!

Maaf keliatannya norak banget saya nulis satu post khusus buat git stash aja. Soalnya saya baru kenal git stash pas kuliah PPL ini 😝. Dan ternyata memang berguna banget saat ada teman setim minta tolong ke saya karena, misalnya, pipeline di Gitlab tiba-tiba failed padahal saya lagi di tengah-tengah implementasi yang barisnya banyak seabrek. Tapi belum selesai. Tapi menurut aturan PPL saya belum boleh commit dulu. Tapi dengan bantuan git Stash saya bisa save dulu hasil pekerjaan saya dan pergi memperbaiki gitlab-ci dan kembali lagi ke implementasi.

Cheers,
Benny William Pardede
Koneg Liquid DevOps

--

--