Melakukan commit — apa itu, aturan format, dan bekerja dengan Git

Apa itu commit di Git

Commit di Git adalah objek yang menyimpan status file proyek pada waktu tertentu. Setiap commit berisi snapshot semua file yang dilacak, referensi ke commit induk, dan metadata. Tidak seperti sistem kontrol versi lainnya, Git menggunakan content-addressable storage — setiap objek diidentifikasi oleh hash SHA-1 dari kontennya.

Ketika pengembang melakukan commit perubahan, Git membuat commit object yang menyimpan: tree object (struktur file), hash commit induk, penulis, committer, tanggal, dan pesan. Objek ini tidak dapat diubah — setelah dibuat, commit tidak dapat dimodifikasi tanpa mengubah hash-nya. Sifat tidak berubah inilah yang menjamin integritas riwayat proyek.

# Siapkan perubahan dan lakukan commit
git add index.html style.css
git commit -m "Fix responsive layout on mobile devices"

# Lihat detail commit
git log --oneline -3
git show HEAD

# Siapkan semua perubahan dan lakukan commit dalam satu langkah
git commit -a -m "Update dependencies to latest versions"

Commit membentuk graf asiklik terarah (DAG), di mana setiap commit baru merujuk ke yang sebelumnya. Ini memungkinkan navigasi riwayat, pembatalan perubahan, dan analisis evolusi basis kode. Memahami struktur Git DAG — dasar untuk bekerja dengan commit secara lanjutan.

Cara melakukan commit perubahan dengan benar

Proses commit di Git terdiri dari dua tahap: menambahkan perubahan ke staging area (indeks) dan membuat commit. Staging area memungkinkan pengembang memilih perubahan mana yang akan masuk ke commit, bahkan jika banyak file diubah di direktori kerja.

Aturan atomisitas — prinsip kunci commit yang baik. Setiap commit harus berisi satu perubahan logis. Jika pengembang memperbaiki bug dan merefaktor kode — itu dua commit berbeda. Commit atomis menyederhanakan code review, pembatalan perubahan, dan analisis riwayat.

Sebelum melakukan commit, ada baiknya memeriksa: apakah masih ada output debug, blok yang dikomentari, atau perubahan tidak sengaja di kode. Untuk ini digunakan perintah git diff --cached, yang menunjukkan apa yang akan masuk ke commit. Pemeriksaan tambahan melalui git status menampilkan daftar file di staging area.

• Periksa perubahan — git diff --cached menunjukkan apa yang masuk ke commit
• Periksa kualitas — kode harus lulus linter dan tes sebelum commit
• Tulis pesan — deskripsi tujuan perubahan yang jelas
• Periksa staged — git status mengonfirmasi daftar file

Aturan penulisan pesan commit

Pesan commit adalah dokumentasi perubahan untuk pengembang masa depan. Pesan yang baik menjawab pertanyaan: apa yang diubah dan mengapa. Konvensi Conventional Commits (tim Angular, 2016) telah menjadi standar bagi banyak proyek dan menentukan format: tipe(bidang): deskripsi.

Pesan commit yang baik terdiri dari judul (hingga 50 karakter) dan badan (opsional, hingga 72 karakter per baris). Judul ditulis dalam bentuk imperatif: “Add” bukan “Added” atau “Adds”. Huruf kapital dan titik di akhir judul tidak digunakan — ini adalah konvensi internasional Git.

Pesan buruk: “fix things” atau “update” — tidak membawa informasi. Sebulan kemudian pengembang tidak akan bisa memahami apa yang diubah dan mengapa. Pesan baik: “fix(payment): handle timeout in stripe callback” — langsung jelas di mana dan apa yang diperbaiki.

Kesalahan umum saat commit

Pengembang, terutama pemula, sering melakukan kesalahan umum saat commit. Yang paling umum — commit terlalu besar yang mencampur puluhan perubahan. Commit seperti itu tidak dapat dibatalkan sebagian, dan code review menjadi siksaan.

Kesalahan kedua paling umum — pesan commit yang buruk. Pesan seperti “fix”, “update”, “changes” atau “wip” tidak memberikan konteks bagi pengembang masa depan. Setelah enam bulan tidak ada yang akan ingat apa yang diperbaiki. Aturannya sederhana: bayangkan setahun lagi Anda melihat riwayat dan mencoba menemukan perubahan tertentu.

Kesalahan ketiga — commit kode yang tidak dikompilasi atau tidak berfungsi. Setelah commit, kode setidaknya harus bisa dikompilasi. Build yang tidak rusak — persyaratan dasar untuk setiap commit ke cabang bersama. Untuk ini, sebelum commit, build dan tes dijalankan.

Kesalahan keempat — commit dengan data rahasia. Kunci API, kata sandi, dan token tidak boleh masuk ke riwayat Git. Jika rahasia sudah di-commit, tidak cukup hanya menghapusnya di commit baru — harus dihapus dari seluruh riwayat melalui git filter-branch atau BFG Repo-Cleaner.

Teknik lanjutan bekerja dengan commit

Git menyediakan alat untuk mengelola riwayat commit. Salah satu yang paling berguna adalah git commit --amend, yang memungkinkan melengkapi commit terakhir dengan perubahan baru atau memperbaiki pesan. Ini berguna jika pengembang lupa menyertakan file atau salah dalam pesan.

# Perbaiki pesan commit terakhir
git commit --amend -m "fix(auth): correct token validation logic"

# Tambahkan file yang terlewat ke commit terakhir
git add missed-file.txt
git commit --amend --no-edit

# Rebase interaktif untuk 3 commit terakhir
git rebase -i HEAD~3

Interactive rebase — alat yang kuat untuk menulis ulang riwayat. Memungkinkan menggabungkan commit (squash), mengubah pesan (reword), mengubah urutan (reorder), dan menghapus commit (drop). Namun rebase mengubah riwayat, sehingga hanya diterapkan pada commit lokal yang belum dikirim ke repositori jarak jauh.

Untuk membatalkan commit ada dua pendekatan. git revert membuat commit baru yang membatalkan perubahan sebelumnya — cara aman yang menjaga riwayat. git reset menghapus commit dari riwayat — berbahaya jika commit sudah dikirim. Dalam pengembangan tim, hanya git revert yang digunakan untuk membatalkan commit yang sudah dipublikasikan.