Penggabungan (merge) — apa itu, cara kerja merge dan strategi penggabungan

Apa itu merge di Git

Merge — adalah perintah git merge yang menggabungkan perubahan dari cabang yang ditentukan ke dalam cabang saat ini. Git menemukan leluhur bersama (commit dasar bersama), menghitung diff setiap cabang relatif terhadap leluhur, dan membuat merge-commit yang berisi kumpulan perubahan gabungan. Hasilnya — cabang target dilengkapi dengan semua perubahan dari cabang yang digabungkan.

Sintaks: berada di cabang target (misalnya main), jalankan git merge feature. Git secara otomatis membuat merge-commit jika tidak ada konflik. Dalam pesan default merge-commit tertulis: “Merge branch ’feature’ into main”. Pesan dapat diubah melalui flag -m atau diedit di editor yang terbuka.

Merge adalah operasi non-destruktif. Berbeda dengan rebase, merge tidak menyentuh commit yang ada: commit tetap dengan hash, penulis, dan tanggal yang sama. Ini menjadikan merge satu-satunya cara aman untuk menggabungkan cabang yang dikerjakan oleh beberapa pengembang secara bersamaan. Jika ada yang salah, merge dapat dibatalkan dengan perintah git merge --abort.

# Beralih ke cabang target
git checkout main

# Gabungkan cabang fitur
git merge feature

# Hasil — merge-commit dengan dua induk
git log --oneline --graph

# Gabungkan dengan pesan kustom
git merge feature -m "feat: integrate authentication module"

Jenis merge: regular, squash, fast-forward

Git mendukung tiga mode penggabungan yang dipilih tergantung pada hasil yang diinginkan. Regular merge (default) membuat merge-commit. Squash merge menggabungkan semua commit cabang fitur menjadi satu. Fast-forward — memindahkan pointer cabang tanpa membuat commit, jika memungkinkan. Pemilihan mode tergantung pada workflow tim dan aturan sejarah.

Regular merge (--no-ff) — membuat merge-commit bahkan jika penggabungan dapat dilakukan sebagai fast-forward. Direkomendasikan untuk cabang main: merge-commit secara eksplisit menandai momen integrasi fitur dan memungkinkan pengembalian mudah semua perubahan cabang fitur dengan satu revert pada merge-commit. GitHub menggunakan mode ini secara default saat menggabungkan PR melalui tombol Merge.

Squash merge (--squash) — mengumpulkan semua commit cabang fitur menjadi satu commit di cabang target. Berguna ketika sejarah kasar cabang fitur tidak boleh masuk ke main. Kekurangan: koneksi dengan commit asli hilang — tidak dapat melihat bagaimana fitur dikembangkan langkah demi langkah. GitHub menggunakan mode ini saat memilih “Squash and merge” di PR.

Fast-forward (--ff) — jika cabang target tidak memiliki commit baru setelah percabangan fitur, Git hanya memindahkan pointer ke depan, tanpa membuat merge-commit. Sejarah tetap linier. Flag --no-ff memaksa pembuatan merge-commit, --ff-only akan berakhir dengan error jika fast-forward tidak memungkinkan.

# Paksa merge-commit (direkomendasikan untuk main)
git merge --no-ff feature

# Squash merge — semua commit menjadi satu
git merge --squash feature
git commit -m "feat: add authentication"

# Fast-forward hanya jika memungkinkan
git merge --ff-only feature

# Batalkan merge yang berkonflik
git merge --abort

Strategi penggabungan Git

Strategi penggabungan menentukan algoritma yang digunakan Git untuk menggabungkan perubahan. Setiap strategi cocok untuk skenario yang berbeda. Git secara otomatis memilih strategi yang sesuai, tetapi pengembang dapat menentukannya secara eksplisit melalui flag --strategy. Memahami strategi membantu memprediksi perilaku Git pada penggabungan yang kompleks.

Recursive — strategi default untuk menggabungkan dua cabang. Git menemukan leluhur bersama, menghitung perubahan di setiap cabang, dan menggabungkannya. Jika leluhur bersama ditemukan, recursive menangani dengan benar penggantian nama file dan penambahan file baru. Pada konflik, recursive dapat menggunakan opsi tambahan: ours (secara otomatis memilih versi kita) dan theirs (memilih versi mereka).

Octopus — untuk penggabungan simultan lebih dari dua cabang: git merge feature1 feature2 feature3. Octopus tidak mendukung resolusi konflik — semua konflik harus diselesaikan sebelum pemanggilan perintah. Jarang digunakan, terutama untuk menggabungkan beberapa cabang independen yang dijamin tidak bertentangan (misalnya modul berbeda).

Ours — strategi khusus yang sepenuhnya mengabaikan perubahan dari cabang yang digabungkan dan mempertahankan konten saat ini dari cabang target. Merge-commit dibuat, tetapi konten tetap tidak berubah. Berguna ketika Anda perlu mencatat fakta penggabungan dalam sejarah tetapi secara praktis menolak semua perubahan dari cabang lain.

Menyelesaikan konflik merge

Konflik merge terjadi ketika baris yang sama dari sebuah file diubah secara berbeda di kedua cabang. Git tidak dapat secara otomatis menentukan versi mana yang benar dan menjeda merge. Konflik juga dapat terjadi saat penggantian nama file di satu cabang dan perubahannya di cabang lain, atau saat penghapusan dan modifikasi simultan dari file yang sama.

Proses penyelesaian: Git menandai file yang berkonflik dengan marker. Di file muncul bagian dengan <<<<<<< HEAD (versi kita), ======= (pemisah), dan >>>>>>> feature (versi mereka). Pengembang secara manual mengedit bagian konflik, memilih baris yang diperlukan dari kedua versi, menghapus marker, menyimpan file, dan menambahkannya ke indeks melalui git add.

Untuk resolusi konflik visual, Git mendukung mergetool — alat perbandingan eksternal. Alat mergetool populer: Meld, KDiff3, Beyond Compare, VS Code (editor konflik bawaan). Mergetool menampilkan tiga panel: versi kita, versi mereka, dan hasilnya. Pengembang secara visual memilih blok kode untuk dimasukkan ke dalam file akhir.

# Mulai merge dan deteksi konflik
git merge feature
# KONFLIK (konten): Konflik merge di src/main.swift

# Periksa file yang berkonflik
git status

# Buka mergetool visual
git mergetool

# Setelah resolusi — tambah dan commit
git add src/main.swift
git commit

# Batalkan merge
git merge --abort

Kapan memilih merge daripada rebase

Merge lebih diutamakan daripada rebase dalam beberapa situasi kunci. Pertama: saat bekerja dengan cabang publik yang dapat diakses oleh pengembang lain. Merge tidak menimpa sejarah, dan rekan kerja dapat melakukan sinkronisasi dengan aman. Rebase di cabang publik akan menciptakan sejarah yang divergen dan konflik bagi semua orang yang sudah menerima commit lama.

Situasi kedua: saat menyelesaikan cabang fitur. Sebagian besar tim lebih memilih merge (dengan flag --no-ff) ke main untuk mencatat momen integrasi fitur. Ini menyederhanakan navigasi melalui sejarah dan memungkinkan pengembalian mudah seluruh fitur dengan satu git revert dari merge-commit. GitHub Flow secara default menawarkan tiga opsi merge: merge sederhana, squash merge, dan rebase merge.

Situasi ketiga: saat bekerja dengan pull request yang telah melalui review. GitHub dan GitLab menawarkan tombol merge dengan berbagai opsi. Merge (Create a merge commit) — sejarah lengkap dengan merge-commit. Squash and merge — sejarah bersih tanpa detail pengembangan. Rebase and merge — sejarah linier tanpa merge-commit, tetapi dengan penimpaan commit. Pilihan tergantung pada aturan tim.

• Cabang publik (main, develop) — hanya merge, jangan pernah rebase.
• Menyelesaikan PR — merge dengan --no-ff untuk mencatat momen integrasi.
• Cabang dengan commit pihak lain — merge tidak menimpa pekerjaan orang lain.
• Sebelum rilis — merge lebih aman karena memiliki lebih sedikit risiko.
• Cabang bersama — jika beberapa pengembang bekerja pada cabang, merge wajib.

Praktik terbaik penggabungan cabang

Aturan pertama: selalu berada di versi terbaru cabang target sebelum merge. Jalankan git checkout main && git pull sebelum menggabungkan fitur. Ini meminimalkan konflik dan menjamin bahwa merge-commit akan berisi semua perubahan terkini. Jika cabang target sudah jauh maju, jalankan dulu git merge main di dalam cabang fitur untuk menyelesaikan konflik dalam konteksnya.

Aturan kedua: uji kode setelah merge. Merge dapat mengubah perilaku, bahkan jika tidak ada konflik. Pipeline CI/CD harus menjalankan tes pada merge-commit sebelum dikirim ke produksi. Beberapa tim menggunakan merge gates — pemeriksaan wajib yang memblokir merge sampai lulus.

Aturan ketiga: dokumentasikan merge-commit. Pesan standar “Merge branch ’feature’ into main” kurang bermanfaat. Disarankan untuk menambahkan deskripsi tentang apa yang digabungkan: “Merge authentication module: login, registration, password recovery”. Ini menyederhanakan analisis sejarah dan pencarian regresi. Di proyek besar, merge-commit secara otomatis dihasilkan dari nama PR.

• Kekinian — sebelum merge, pastikan cabang target telah diperbarui (git pull).
• Pengujian — CI/CD harus menjalankan tes pada merge-commit yang dihasilkan.
• Pesan deskriptif — sebutkan di merge-commit fitur apa yang digabungkan.
• Frekuensi — gabungkan cabang fitur sedini dan sesering mungkin (maksimal seminggu).
• Pembatalan — git revert dari merge-commit membatalkan seluruh fitur sepenuhnya.