Kalau kamu sering pakai `GitHub`, pasti nggak asing sama tiga pilihan ini pas mau menggabungkan *`Pull Request`* (PR). Kadang bikin bingung, "sebaiknya pilih yang mana, ya?". Tenang, nggak ada jawaban yang 100% benar atau salah kok. Pilihan ini lebih ke soal selera dan gaya kerja tim kamu.
Biar gampang, yuk kita pakai analogi sederhana: anggap aja branch `main` kamu itu sebuah buku cerita, dan setiap PR adalah proses kamu nulis satu bab baru.
1. Allow merge commits (Opsi Standar)
Ini adalah cara `git merge` yang paling standar dan klasik.
Analogi Bab Buku 📖
Kamu menulis draf bab baru di kertas-kertas terpisah (ini adalah commit-commit di branch kamu). Saat selesai, kamu mengambil semua kertas draf itu dan menggabungkannya ke buku utama dengan satu catatan tambahan: "Bab ini selesai, ini semua drafnya".
Kelebihan & Kekurangan
- **Menjaga konteks penuh.** Kamu bisa lihat persis gimana sebuah fitur dikembangkan, langkah demi langkah, dari awal sampai akhir. Semua jejaknya terekam rapi.
- **Membuat riwayat `main` jadi "ramai".** Riwayatnya bakal penuh sama commit-commit kecil seperti "fix typo", "coba ini", "revert", yang sebenarnya nggak terlalu penting untuk dilihat di gambaran besar proyek.
2. Allow squash merging (Opsi Paling Populer)
Opsi ini menggabungkan semua commit di PR kamu menjadi **satu commit tunggal** yang rapi di branch `main`.
Analogi Bab Buku 📝
Kamu menulis banyak draf di kertas terpisah, coret-coret sana-sini. Setelah babnya sempurna, kamu membuang semua draf lama dan hanya menyalin hasil akhirnya ke dalam satu halaman bersih di buku utama dengan judul: "Menambahkan Bab Tentang Pajak".
Kelebihan & Kekurangan
- **Riwayat `main` super bersih dan mudah dibaca.** Setiap commit mewakili satu PR yang tuntas. Gampang banget buat melacak kapan sebuah fitur ditambahkan atau bahkan untuk mengembalikan (`revert`) seluruh fitur jika ternyata bikin masalah.
- **Kehilangan detail proses.** Kamu nggak bisa lagi lihat langkah-langkah kecil atau *trial-error* yang terjadi selama proses pengerjaan fitur tersebut, karena semuanya sudah dilebur jadi satu.
3. Allow rebase merging (Opsi Paling ’Rapi’ tapi Kompleks)
Opsi ini mengambil semua commit kamu dan "memainkannya kembali" satu per satu di atas branch `main`, menciptakan sejarah yang lurus sempurna.
Analogi Bab Buku 📜
Kamu menulis draf di kertas terpisah. Sebelum memasukkannya ke buku, kamu menyusun ulang draf-draf tersebut seolah-olah kamu menulisnya secara berurutan langsung di akhir buku, tanpa ada pekerjaan sampingan sama sekali.
Kelebihan & Kekurangan
- **Menghasilkan riwayat yang paling bersih dan lurus (linear).** Tidak ada jejak "merge commit" sama sekali, membuat alur sejarah proyek sangat mudah diikuti secara kronologis.
- **Ini "menulis ulang sejarah", yang bisa berbahaya.** Kalau branch tersebut dikerjakan oleh lebih dari satu orang, `rebase` bisa bikin pusing dan menyebabkan konflik. Butuh pemahaman Git yang lebih dalam untuk menggunakannya dengan aman.
Jadi, Mana yang Paling Pas Buat Saya?
Melihat dari konteks kamu yang mengelola blog atau situs pribadi, saya **sangat merekomendasikan untuk memilih Squash Merging.** Ini adalah jalan tengah terbaik yang memberikan riwayat super bersih tanpa kompleksitas dari `rebase`. Tiap artikel baru atau tiap perbaikan desain akan jadi satu commit yang jelas di riwayat proyekmu.
**Saran Praktis:** Coba deh aktifkan HANYA `Allow squash merging` dan matikan dua lainnya. Ini akan membiasakan kamu untuk selalu menjaga riwayat Git tetap bersih dan mudah dimengerti.
Tabel Perbandingan Cepat
| Opsi | Riwayat di Branch `main` | Kapan Cocok Digunakan |
|---|---|---|
| **Merge Commit** | Bercabang dan "ramai" | Proyek besar di mana detail proses pengerjaan penting untuk diaudit. |
| **Squash Merge** | Linear dan ringkas ✅ | Proyek pribadi, tim kecil, atau proyek apa pun yang ingin riwayatnya bersih. |
| **Rebase Merge** | Sangat lurus, tanpa jejak merge | Proyek yang menuntut riwayat linear sempurna dan dikerjakan oleh developer yang sangat paham Git. |