Foto oleh Zulfugar Karimov via Pexels

Setelah memahami konsep dasar Git, langkah selanjutnya adalah menguasai perintah-perintah inti yang dipakai sehari-hari: add untuk menandai perubahan, commit untuk menyimpannya secara permanen, push untuk mengirim perubahan ke repository remote, dan pull untuk mengambil perubahan terbaru dari remote.

Memahami alur kerja perintah-perintah ini bukan sekadar menghafal sintaksnya, melainkan memahami apa yang sebenarnya terjadi di balik layar pada ketiga area kerja Git (working directory, staging, repository) setiap kali perintah tersebut dijalankan.

Artikel ini membahas penggunaan praktis git add, commit, push, dan pull, termasuk variasi perintah yang berguna seperti commit dengan pesan yang baik dan menangani konflik sederhana saat melakukan pull.

Git Add untuk Staging Perubahan

Berbagai variasi git add untuk kontrol staging yang berbeda

git add file1.txt # stage satu file spesifik git add src/ # stage seluruh folder src git add . # stage SEMUA perubahan di folder saat ini git add -p file1.txt # stage SEBAGIAN perubahan dalam file (interaktif)
git add -p sangat berguna ketika satu file memiliki beberapa perubahan berbeda yang sebaiknya dipisah menjadi commit terpisah, memungkinkan developer memilih secara interaktif bagian mana dari perubahan file tersebut yang akan disertakan dalam staging saat ini, dan mana yang akan di-commit secara terpisah nanti.

Git Commit dengan Pesan yang Baik

Pesan commit yang deskriptif memudahkan penelusuran riwayat

git commit -m "Tambah validasi email pada form registrasi" # Pesan commit yang baik: jelas, singkat, menjelaskan APA # yang berubah dan KENAPA, bukan sekadar "update" atau "fix bug"
Pesan commit yang baik dan deskriptif sangat membantu ketika developer (termasuk diri sendiri di masa depan) perlu memahami riwayat perubahan project, jauh lebih berguna dibanding pesan generik seperti 'update' atau 'fix' yang tidak menjelaskan apa sebenarnya yang berubah dan mengapa perubahan tersebut dilakukan.

Git Push ke Repository Remote

Push mengirim commit lokal ke repository remote

git push origin main # origin -> nama default remote repository (biasanya GitHub) # main -> nama branch yang di-push git push -u origin main # -u menyimpan konfigurasi tracking # sehingga 'git push' saja sudah cukup selanjutnya
Git push mengirim commit yang sudah tersimpan di repository lokal ke repository remote seperti GitHub, membuatnya tersedia bagi developer lain. Flag -u pada push pertama kali menyimpan konfigurasi tracking antara branch lokal dan remote, sehingga push selanjutnya cukup ditulis git push tanpa perlu menyebutkan origin dan nama branch lagi.

Git Pull untuk Mengambil Perubahan Terbaru

Pull adalah kombinasi fetch dan merge dalam satu perintah

git pull origin main # git pull sebenarnya adalah gabungan dari: # git fetch (ambil perubahan remote TANPA merge) # git merge (gabungkan perubahan tersebut ke branch lokal)
Git pull sebenarnya merupakan kombinasi dua operasi: fetch yang mengambil data terbaru dari remote tanpa langsung menggabungkannya, dan merge yang menggabungkan perubahan tersebut ke branch lokal yang sedang aktif, dan memahami kedua langkah terpisah ini membantu saat perlu menangani konflik yang muncul selama proses merge tersebut.

Mengelola Perubahan yang Belum Siap Commit dengan Git Stash

Menyimpan sementara perubahan yang belum selesai untuk berpindah branch

$ git status modified: ProdukController.cs $ git stash save "WIP: validasi harga produk" Saved working directory and index state WIP: validasi harga produk $ git checkout branch-lain $ git checkout fitur-produk $ git stash pop # perubahan ProdukController.cs kembali muncul di working directory

Git stash berguna ketika sedang mengerjakan perubahan di suatu branch namun perlu berpindah ke branch lain untuk mengerjakan sesuatu yang mendesak, sementara perubahan saat ini belum siap untuk di-commit. Perintah git stash save menyimpan seluruh perubahan pada working directory ke tumpukan sementara dan mengembalikan working directory ke kondisi bersih sesuai commit terakhir.

Perubahan yang sudah di-stash bisa dikembalikan kapan saja dengan git stash pop, yang akan menerapkan kembali perubahan tersebut sekaligus menghapusnya dari tumpukan stash. Jika ingin menerapkan perubahan tanpa menghapusnya dari stash, bisa memakai git stash apply, yang berguna ketika perubahan yang sama ingin diterapkan ke lebih dari satu branch.

Git Bisect untuk Mencari Commit Penyebab Bug Secara Sistematis

Binary search otomatis lewat git bisect untuk menemukan commit penyebab bug

$ git bisect start $ git bisect bad # commit saat ini diketahui bermasalah $ git bisect good v1.0.0 # versi ini diketahui masih berfungsi normal # Git otomatis checkout ke commit tengah, lalu uji manual: Bisecting: 12 revisions left to test after this (roughly 4 steps) $ git bisect good # jika commit ini masih baik-baik saja $ git bisect bad # jika bug sudah muncul di commit ini # ...ulangi sampai Git menunjukkan commit penyebab persis # a3f9c2e is the first bad commit $ git bisect reset # kembali ke branch semula setelah selesai

Mencari commit mana yang menyebabkan bug muncul di antara ratusan commit bisa sangat memakan waktu jika dilakukan dengan membaca riwayat satu per satu. Git bisect menyediakan mekanisme binary search otomatis: cukup menandai satu commit yang diketahui bermasalah (bad) dan satu commit yang diketahui masih normal (good), Git akan memilih commit tepat di tengah rentang tersebut untuk diuji. Teknik ini jauh lebih efisien dibanding memeriksa commit satu per satu secara berurutan dari awal sampai akhir riwayat.

Pada setiap commit yang di-checkout otomatis oleh Git, developer menjalankan pengujian manual atau otomatis untuk memastikan apakah bug sudah muncul pada titik tersebut, lalu melaporkan hasilnya kembali lewat git bisect good atau git bisect bad. Proses ini berulang dengan rentang pencarian yang terus dipersempit separuh setiap kali, sehingga menemukan commit penyebab di antara seribu commit hanya membutuhkan sekitar sepuluh kali pengujian saja. Hasil akhir bisect berupa satu commit tunggal yang bisa langsung dianalisis lebih lanjut untuk memahami perubahan apa yang memicu bug.

Git bisect juga mendukung mode run yang menerima script pengujian otomatis sebagai argumen, sehingga seluruh proses bisa berjalan tanpa campur tangan manual sama sekali, cocok dipakai bersama test suite otomatis yang mengembalikan exit code berbeda untuk kondisi lulus dan gagal. Setelah commit penyebab ditemukan, git bisect reset wajib dijalankan untuk mengembalikan repository ke branch semula sebelum proses bisect dimulai. Kombinasi git bisect run dengan test otomatis membuat proses pencarian bug bisa dijalankan tanpa pengawasan, bahkan saat developer mengerjakan tugas lain.

Menyelamatkan Commit yang Hilang lewat Git Reflog

Reflog mencatat setiap perpindahan HEAD, termasuk sebelum reset dijalankan

$ git reset --hard HEAD~3 # Tiga commit terakhir "hilang" dari riwayat branch saat ini $ git reflog a3f9c2e HEAD@{0}: reset: moving to HEAD~3 e4f1a2c HEAD@{1}: commit: tambah validasi diskon d3c9b81 HEAD@{2}: commit: perbaiki harga minimum ... $ git reset --hard e4f1a2c # Branch kembali ke kondisi sebelum reset, commit yang "hilang" pulih kembali

Git reflog mencatat setiap perpindahan posisi HEAD pada repository lokal, termasuk saat commit dibuat, branch dipindah, atau reset dijalankan, bahkan untuk commit yang sudah tidak terlihat lagi di git log biasa. Catatan ini bersifat lokal dan tidak ikut terkirim saat push, namun sangat berguna untuk memulihkan pekerjaan yang tampak hilang akibat kesalahan perintah seperti git reset --hard yang keliru.

Dengan melihat daftar reflog, posisi commit sebelum perintah yang bermasalah dijalankan bisa ditemukan lewat hash commit yang masih tercatat, lalu dipulihkan kembali memakai git reset ke hash tersebut. Reflog memiliki masa retensi terbatas secara default sekitar sembilan puluh hari, sehingga bukan pengganti backup permanen, melainkan jaring pengaman untuk kesalahan yang baru saja terjadi.

Kesalahan Umum yang Sering Terjadi

Melupakan Git Add Sebelum Commit

Menjalankan git commit tanpa git add terlebih dahulu untuk perubahan baru akan menghasilkan commit yang kosong atau tidak menyertakan perubahan yang dimaksud, karena commit hanya menyimpan apa yang sudah ada di staging area.

Menulis Pesan Commit yang Tidak Informatif

Pesan commit seperti 'update', 'fix', atau 'asdf' tidak memberikan informasi apa pun tentang perubahan yang dilakukan, menyulitkan tim (termasuk diri sendiri) memahami riwayat project ketika perlu ditelusuri di kemudian hari.

Melakukan Push Tanpa Pull Terlebih Dahulu

Mencoba push ketika branch remote sudah memiliki commit baru yang belum ada di lokal akan ditolak Git, mengharuskan pull terlebih dahulu untuk menggabungkan perubahan remote sebelum push bisa berhasil dilakukan.

Kapan Pendekatan Ini Tidak Cocok Dipakai

Melakukan commit secara sering dengan perubahan kecil memudahkan penelusuran riwayat dan rollback yang presisi, namun bisa menghasilkan riwayat commit yang sangat panjang dan berantakan jika tidak dikelola dengan baik.

Melakukan commit jarang dengan perubahan besar sekaligus menghasilkan riwayat yang lebih ringkas, namun menyulitkan jika perlu rollback sebagian kecil perubahan saja tanpa membatalkan seluruh perubahan besar yang tergabung dalam satu commit tersebut.

Ringkasan

Perintah dasar Git, add, commit, push, dan pull, membentuk alur kerja inti yang dipakai setiap hari oleh developer yang memakai version control. Biasakan menulis pesan commit yang deskriptif dan pahami apa yang sebenarnya terjadi pada ketiga area kerja Git setiap kali perintah tersebut dijalankan.

Seri Belajar Git & CI/CD:

← Sebelumnya: Pengenalan Git dan Version Control System

→ Selanjutnya: Branching Strategy dan Git Flow