Merge — apa itu, tipe penggabungan dan mekanisme kerja

Apa itu Merge?

Merge (penggabungan) — adalah operasi fundamental di Git yang menggabungkan perubahan dari satu cabang (source) ke cabang lain (target). Sebagai hasil penggabungan, cabang target menerima semua commit dari cabang sumber yang belum ada di dalamnya. Tergantung pada situasi, Git dapat melakukan merge dengan tiga cara berbeda.

Nilai utama merge — preservasi sejarah: merge commit mencatat fakta penggabungan cabang, menyimpan informasi tentang kapan dan cabang mana yang digabungkan. Ini memfasilitasi audit perubahan, pencarian regresi, dan pemahaman kronologi pengembangan. Dalam proyek besar, merge commit adalah cara standar integrasi kode.

Menurut data GitLab Flow, merge commit digunakan di 73% tim yang bekerja dengan Git. Pendekatan alternatif (rebase, squash) lebih disukai oleh tim yang berorientasi pada sejarah linier. Pemilihan strategi tergantung pada ukuran tim, frekuensi rilis, dan kesepakatan yang diterima dalam proyek.

Kapan Merge diperlukan

Merge diperlukan ketika pengembang telah menyelesaikan pekerjaan pada fitur dan ingin mengintegrasikannya ke develop atau main. Skenario tipikal: pengembang membuat cabang fitur dari develop, bekerja selama beberapa hari, dan selama waktu itu muncul commit baru di develop dari peserta lain. Sebelum penggabungan, perubahan perlu digabungkan — dan untuk itulah merge digunakan.

Tanpa merge, tidak mungkin bekerja bersama pada satu kode di Git. Setiap kali dua pengembang secara bersamaan melakukan perubahan pada basis kode yang sama, cabang mereka menyimpang. Merge — satu-satunya cara untuk menyatukan kembali perubahan ini tanpa kehilangan data.

Tipe penggabungan di Git

Git mendukung tiga tipe merge, masing-masing ditujukan untuk skenarionya sendiri. Pilihan tipe penggabungan mempengaruhi sejarah commit, kenyamanan pengembalian, dan keterbacaan log.

Fast-forward merge

Fast-forward terjadi ketika cabang target tidak memiliki commit baru sejak pembuatan cabang sumber. Dalam kasus ini, Git cukup memindahkan penunjuk cabang target ke depan, ke commit terakhir cabang sumber. Sejarah tetap linier, tanpa merge commit.

# Fast-forward merge: develop tidak berubah sejak pembuatan feature
git checkout develop
git merge feature/new-login

# Hasil: penunjuk develop berpindah ke akhir feature
# Tidak ada merge commit yang dibuat

Fast-forward nyaman untuk cabang berumur pendek, di mana pengembang bekerja sendiri. Namun pendekatan ini memiliki kekurangan: informasi bahwa cabang itu ada hilang — semua commit terlihat seperti dibuat langsung di develop.

Three-way merge

Three-way merge dilakukan ketika kedua cabang memiliki commit baru setelah titik divergensi. Git membuat merge commit terpisah dengan dua orang tua, yang mencatat fakta penggabungan cabang. Pendekatan ini direkomendasikan untuk cabang fitur dalam pengembangan tim.

# Three-way merge paksa dengan bendera --no-ff
git checkout develop
git merge --no-ff feature/new-login

# Merge commit dibuat dengan pesan default
# Dapat mengatur pesan sendiri melalui -m
git merge --no-ff feature/new-login -m "Merge feature/new-login into develop"

Bendera --no-ff menjamin pembuatan merge commit, bahkan jika fast-forward memungkinkan. Ini adalah praktik terbaik untuk menjaga informasi tentang percabangan dalam proyek.

Squash merge

Squash merge memampatkan semua commit cabang sumber menjadi satu dan menerapkannya ke cabang target. Sejarah fitur hilang — satu commit dengan semua perubahan masuk ke cabang. Ini nyaman ketika commit detail di cabang fitur tidak memberikan nilai bagi sejarah umum.

# Squash merge: semua commit feature dimampatkan menjadi satu
git checkout develop
git merge --squash feature/experimental
git commit -m "feat: experimental login flow (squashed)"

Squash cocok untuk draf, cabang eksperimental, dan situasi di mana menjaga kebersihan sejarah itu penting. Minus — hubungan dengan commit asli hilang, yang mempersulit pengembalian perubahan individual.

Strategi Ours dan Theirs

Ours dan Theirs — dua strategi merge khusus di Git. Ours sepenuhnya mengabaikan perubahan dari cabang sumber, hanya mempertahankan apa yang ada di cabang target. Theirs, sebaliknya, menerima versi cabang sumber pada setiap konflik. Strategi ini berguna saat menggabungkan volume kode yang besar, ketika sudah diketahui sebelumnya versi mana yang harus menang.

Bagaimana Merge bekerja

Mekanisme merge di Git didasarkan pada perbandingan tiga titik: nenek moyang bersama (merge base), keadaan cabang sumber, dan keadaan cabang target. Git menemukan merge base — commit terakhir yang umum untuk kedua cabang — dan menghitung perubahan apa yang terjadi di setiap cabang setelah divergensi.

• Langkah 1 — Git menentukan merge base: commit terakhir yang ada di kedua cabang
• Langkah 2 — Git membangun dua diff: dari merge base ke source dan dari merge base ke target
• Langkah 3 — Git mencoba menerapkan kedua set perubahan ke merge base
• Langkah 4 — Jika perubahan tidak bertentangan — merge selesai secara otomatis
• Langkah 5 — Jika ada konflik — Git berhenti dan meminta penyelesaian

Git menggunakan algoritma tiga arah penggabungan, yang mempertimbangkan tidak hanya dua versi file yang dibandingkan, tetapi juga nenek moyang bersama mereka. Berkat ini, Git dapat secara otomatis menyelesaikan situasi di mana perubahan di satu cabang tidak mempengaruhi bagian yang diubah di cabang lain — bahkan jika kedua file telah dimodifikasi.

Algoritma kerja merge dengan contoh

Pertimbangkan skenario: dua pengembang bekerja pada file berbeda dalam cabang fitur yang sama. Yang pertama mengubah LoginActivity.kt, yang kedua — ProfileFragment.kt. Ketika mereka menggabungkan perubahan mereka, Git melihat bahwa perubahan tersebut mengenai file yang berbeda dan melakukan merge secara otomatis, tanpa campur tangan manusia.

Jika kedua pengembang mengubah LoginActivity.kt, tetapi di metode yang berbeda — Git juga akan menanganinya secara otomatis, menggabungkan perubahan baris demi baris. Konflik muncul hanya jika keduanya mengubah baris yang sama atau jika satu menghapus kode yang diubah oleh yang lain.

Menyelesaikan konflik saat Merge

Konflik merge muncul ketika Git tidak dapat menggabungkan perubahan secara otomatis, karena kedua cabang mengubah baris yang sama dengan cara berbeda. Dalam kasus ini, Git menandai bagian konflik di file dan menunggu penyelesaian manual oleh pengembang.

Bagian konflik ditandai dengan penanda khusus: <<<<<<< HEAD menunjukkan kode dari cabang target, ======= — pemisah, >>>>>>> source-branch — kode dari cabang sumber. Pengembang harus secara manual memilih varian mana yang akan dipertahankan atau menggabungkannya.

# 1. Jalankan merge dan lihat konflik
git merge feature/new-login
# Keluaran: CONFLICT (content): Merge conflict in LoginActivity.kt

# 2. Lihat daftar file dengan konflik
git status
# both modified: src/ui/login/LoginActivity.kt

# 3. Selesaikan konflik: edit file, hapus penanda
# 4. Tambahkan file yang sudah diselesaikan dan selesaikan merge
git add src/ui/login/LoginActivity.kt
git merge --continue
# atau: git commit (tanpa --continue)

Untuk menyelesaikan konflik, ada alat: git mergetool membuka merger visual (Meld, Beyond Compare, VS Code). Banyak pengembang lebih suka menyelesaikan konflik di IDE — IntelliJ IDEA dan Android Studio menyediakan alat bawaan dengan perbandingan tiga panel, yang secara signifikan menyederhanakan proses ini.

Tips untuk menyelesaikan konflik: selalu pahami apa yang dilakukan setiap pihak dalam konflik, jangan hapus kode orang lain tanpa memahami logikanya, dan jika konflik terlalu rumit — libatkan penulis kedua cabang untuk penyelesaian bersama.

Merge vs Rebase: kapan memilih apa

Pilihan antara Merge dan Rebase — salah satu keputusan arsitektur paling umum di Git. Kedua pendekatan menggabungkan perubahan, tetapi melakukannya dengan cara berbeda: merge mempertahankan sejarah percabangan, rebase menulis ulang sejarah, membuatnya linier.

• Merge — mempertahankan konteks: terlihat kapan dan dari cabang mana penggabungan dilakukan. Lebih baik untuk cabang publik (develop, main) dan kerja tim
• Rebase — menciptakan sejarah linier yang bersih tanpa merge commit yang tidak perlu. Lebih baik untuk cabang fitur pribadi sebelum dikirim untuk review
• Aturan: jangan pernah melakukan rebase pada cabang publik yang digunakan oleh pengembang lain

Banyak tim menggunakan pendekatan hibrida: rebase untuk memperbarui cabang fitur ke keadaan develop saat ini (git rebase develop), kemudian merge dengan bendera --no-ff untuk mencatat penggabungan. Ini memberikan sejarah bersih di dalam fitur dan titik penggabungan informatif di tingkat develop.