Menggabungkan cabang — apa itu, cara penggabungan dan resolusi konflik

Apa itu merge di Git

Merge di Git — adalah operasi penggabungan dua atau lebih riwayat pengembangan menjadi satu. Ketika pengembang menggabungkan cabang, Git secara otomatis menemukan leluhur bersama (base commit) dan membuat commit penggabungan baru yang mencakup perubahan dari kedua cabang. Three-way merge — algoritma standar yang membandingkan tiga keadaan: leluhur bersama, cabang pertama, dan cabang kedua.

Proses merge dimulai dengan perintah git merge. Git menentukan titik percabangan dan menerapkan perubahan dari cabang sumber ke cabang target secara berurutan. Jika perubahan tidak bertentangan, Git melakukan fast-forward atau membuat merge commit tergantung pada pengaturan. Fast-forward — skenario di mana cabang target hanya dipindahkan ke commit cabang sumber.

# Beralih ke cabang target dan gabungkan
git checkout main
git merge feature/payment-module

# Gabungkan dengan no-fast-forward eksplisit
git merge --no-ff feature/payment-module

# Batalkan penggabungan jika konflik terlalu kompleks
git merge --abort

Flag --no-ff (no fast-forward) memaksa pembuatan merge commit bahkan ketika fast-forward memungkinkan. Ini menyimpan informasi bahwa perubahan dibuat di cabang terpisah. Banyak tim lebih memilih pendekatan ini untuk mempertahankan percabangan riwayat secara eksplisit.

Cara menggabungkan cabang

Di Git ada tiga strategi utama penggabungan cabang, masing-masing cocok untuk skenario tertentu. Pemilihan strategi tergantung pada budaya tim dan persyaratan kebersihan riwayat proyek.

Standard merge membuat merge commit dengan dua induk. Riwayat lengkap dipertahankan, tetapi grafik percabangan menjadi lebih kompleks. Squash merge menggabungkan semua commit cabang feature menjadi satu dan menerapkannya ke cabang target — riwayat menjadi linier dan bersih, tetapi informasi tentang tahap perantara hilang.

Rebase, meskipun bukan merge sepenuhnya, mencapai hasil yang sama — perubahan dari satu cabang dipindahkan ke cabang lain. Perbedaannya adalah bahwa riwayat ditulis ulang: commit cabang feature dibuat ulang di atas commit terakhir cabang target. Ini memberikan riwayat yang benar-benar linier, tetapi memerlukan force push saat mengirim.

Cara menyelesaikan konflik saat merge

Konflik saat merge terjadi ketika di dua cabang baris yang sama dari sebuah file diubah. Git tidak dapat secara otomatis menentukan versi mana yang harus dipertahankan dan memerlukan campur tangan pengembang. Konflik ditampilkan dalam file sebagai penanda khusus: <<<<<<<, =======, >>>>>>>.

Proses penyelesaian konflik mencakup beberapa langkah. Pertama, pengembang membuka file yang bermasalah dan secara manual memilih perubahan yang diperlukan. Penting untuk tidak hanya memilih salah satu versi, tetapi memahami logika kedua perubahan dan mengambil keputusan yang tepat. Setelah mengedit file, penanda konflik dihapus dan perubahan ditambahkan ke staging area melalui git add.

# Lihat daftar file yang bermasalah
git status

# Jalankan mergetool (mis. VS Code, IntelliJ)
git mergetool

# Setelah menyelesaikan semua konflik
git add .
git merge --continue

# Atau batalkan penggabungan sepenuhnya
git merge --abort

Penggunaan alat merge visual secara signifikan mempercepat penyelesaian konflik. VS Code, IntelliJ IDEA, dan GitKraken menyediakan antarmuka dengan tiga panel: cabang saat ini, cabang masuk, dan hasil. Alat git mergetool secara otomatis membuka editor yang dikonfigurasi untuk setiap file yang bermasalah.

Cara terbaik untuk menghindari konflik yang kompleks adalah sinkronisasi rutin cabang feature dengan cabang utama. Jika pengembang menggabungkan main ke cabangnya sekali sehari, konflik akan kecil dan mudah diselesaikan. Akumulasi perubahan selama seminggu menjamin konflik kompleks dengan risiko kesalahan yang tinggi.

Kapan menggunakan rebase daripada merge

Rebase dan merge — dua cara menggabungkan perubahan, dan pilihan di antara keduanya sering menimbulkan perdebatan dalam tim. Rebase memindahkan commit dari satu cabang ke cabang lain, menulis ulang riwayat. Merge membuat commit penggabungan baru, mempertahankan riwayat percabangan. Setiap pendekatan memiliki kelebihan dan keterbatasannya.

Rebase cocok ketika pengembang bekerja di cabang feature lokalnya dan ingin mendapatkan riwayat linier yang bersih sebelum membuat Pull Request. Setelah rebase, semua commit tersusun secara berurutan, tanpa merge commit yang tidak perlu. Namun, rebase memerlukan force push dan tidak dapat diterapkan pada cabang yang dikerjakan oleh beberapa orang secara bersamaan.

• Rebase — untuk cabang feature pribadi yang membutuhkan riwayat bersih
• Merge — untuk cabang bersama dan pencatatan momen penggabungan
• Squash — ketika cabang feature berisi banyak commit kerja kecil

Aturan emas Git: jangan gunakan rebase pada commit yang sudah dikirim ke repositori bersama. Ini menjamin bahwa riwayat di cabang bersama tetap tidak berubah, dan pengembang lain tidak akan menemukan commit duplikat atau hilang. Untuk integrasi cabang feature ke cabang utama, gunakan merge melalui Pull Request.

Praktik terbaik penggabungan cabang

Proses merge yang benar — dasar pengembangan yang stabil. Dalam kerja tim modern, merge dilakukan tidak melalui konsol, tetapi melalui Pull Request di GitHub atau Merge Request di GitLab. PR melalui code review, pemeriksaan CI otomatis, dan baru kemudian digabungkan ke cabang utama.

Praktik pertama — gabungkan hanya setelah semua pemeriksaan lulus. CI pipeline harus membangun proyek, menjalankan tes, dan memeriksa kualitas kode. Jika setidaknya satu pemeriksaan tidak lulus, merge diblokir. Platform modern (GitHub, GitLab) memiliki perlindungan bawaan: branch protection rules secara otomatis memblokir merge saat CI gagal.

Praktik kedua — jangan pernah menggabungkan kode yang rusak. Sebelum merge, pengembang harus memastikan bahwa perubahannya tidak merusak build dan tidak meregresi fungsionalitas yang ada. Untuk ini ada tes otomatis dan code review.

Praktik ketiga — bersihkan cabang feature setelah merge. Cabang yang sudah digabungkan harus dihapus. Ini mencegah kebingungan dan kekacauan repositori. GitHub secara otomatis menawarkan untuk menghapus cabang setelah merge PR, dan pengaturan repositori dapat dikonfigurasi untuk penghapusan otomatis.