git merge dari section Branch dan Merging dan git rebase dari dua chapter sebelumnya sama-sama menyelesaikan satu masalah: kedua branch telah menyimpang dan harus dipertemukan. Namun keduanya meninggalkan jejak yang berbeda pada riwayat — yang satu jujur bercabang, yang lain rapi lurus — dan pilihan di antara keduanya kerap menjadi perdebatan tim. Cara paling jujur memutuskan adalah melihat kedua hasilnya berdampingan pada skenario yang sama. Chapter ini membangun dua repository kembar, menjalankan rebase-lalu-merge pada yang pertama dan merge biasa pada yang kedua, lalu membandingkan kedua graf beserta konsekuensinya.

Skenario Kembar: Dua Strategi, Satu Titik Berangkat #

Repository pertama dibangun dengan pola yang kini sudah akrab — main maju satu commit selagi fitur menambah dua commit:

bash 
mkdir latihan-vs-rebase && cd latihan-vs-rebase
git init -b main
git config user.name "Budi Santoso"
git config user.email "[email protected]"
printf 'beranda\n' > situs.md
git add situs.md
git commit -m "Buat halaman beranda"
git switch -c fitur-galeri
printf 'galeri foto\n' > galeri.md
git add galeri.md
git commit -m "Tambah halaman galeri"
printf 'album 2026\n' > foto.md
git add foto.md
git commit -m "Tambah halaman foto"
git switch main
printf 'beranda\nfaq\n' > situs.md
git add situs.md
git commit -m "Tambah halaman faq"
git log --oneline --graph --all

Output yang Dihasilkan:

text 
* 1ff77cd Tambah halaman faq
| * c6c9bf1 Tambah halaman foto
| * 66ea7a9 Tambah halaman galeri
|/  
* 7a2408c Buat halaman beranda

Repository kedua, latihan-vs-merge, dibuat dengan urutan perintah yang persis sama — cukup ganti mkdir latihan-vs-rebase menjadi mkdir latihan-vs-merge dan ulangi semua langkahnya sampai commit “Tambah halaman faq”. Graf sebelumnya identik; satu-satunya bedanya nanti ada pada langkah penggabungannya.

Strategi Rebase lalu Merge Fast-Forward #

Pada repository pertama, fitur-galeri dinaikkan dulu ke atas ujung main:

bash 
git switch fitur-galeri
git rebase main

Output yang Dihasilkan:

text 
Successfully rebased and updated refs/heads/fitur-galeri.

Baru kemudian penggabungan dijalankan dari main — dan karena setelah rebase kedua penunjuk berada pada satu garis lurus, merge yang terjadi adalah fast-forward, materi chapter Fast-Forward Merge :

bash 
git switch main
git merge fitur-galeri

Output yang Dihasilkan:

text 
Updating 1ff77cd..695ff49
Fast-forward
 foto.md   | 1 +
 galeri.md | 1 +
 2 files changed, 2 insertions(+)
 create mode 100644 foto.md
 create mode 100644 galeri.md

Tidak ada commit penggabung — hanya penarikan penunjuk. Graf akhirnya:

bash 
git log --oneline --graph --all

Output yang Dihasilkan:

text 
* 695ff49 Tambah halaman foto
* 6ced1ae Tambah halaman galeri
* 1ff77cd Tambah halaman faq
* 7a2408c Buat halaman beranda

Strategi Merge Tanpa Rebase #

Repository kedua tidak menyentuh fitur-galeri sama sekali. Dari main, penggabungan langsung dijalankan dengan --no-ff — opsi yang memaksa commit penggabung meski fast-forward mungkin terjadi, sehingga bentuknya konsisten dengan three-way merge dari chapter Three-Way Merge :

bash 
git switch main
git merge --no-ff fitur-galeri -m "Gabungkan fitur galeri"

Output yang Dihasilkan:

text 
Merge made by the 'ort' strategy.
 foto.md   | 1 +
 galeri.md | 1 +
 2 files changed, 2 insertions(+)
 create mode 100644 foto.md
 create mode 100644 galeri.md

Graf akhirnya mempertahankan percabangan asli:

bash 
git log --oneline --graph --all

Output yang Dihasilkan:

text 
*   1ba38da Gabungkan fitur galeri
|\  
| * c6c9bf1 Tambah halaman foto
| * 66ea7a9 Tambah halaman galeri
* | 1ff77cd Tambah halaman faq
|/  
* 7a2408c Buat halaman beranda

Kedua bentuk akhir itu berdiri berdampingan di bawah — hash milik mesin uji, bentuk milik masing-masing strategi:

Perhatikan satu hal yang mengejutkan: isi akhir kedua repository sama persis — berkas, baris, hingga isi situs.md tidak berbeda satu byte. Yang berbeda hanyalah cerita yang diceritakan riwayatnya.

Tabel Perbandingan Menyeluruh #

AspekRebase lalu mergeMerge (langsung)
Bentuk riwayatLinear, seolah percabangan tak terjadiBercabang, mencerminkan kronologi asli
Commit baru saat integrasiTidak ada (fast-forward menarik penunjuk)Satu commit merge berparent dua
Hash commit fiturBerubah — commit ditulis ulang ke basis baruTetap — sejarah asli tidak disentuh
Kapan pas dipakaiMenyegarkan branch pribadi sebelum digabungkanMengintegrasikan fitur ke branch bersama
Resiko utamaMenimbulkan konflik berulang saat ditulis ulang; hash beda dengan salinan rekanRiwayat bertambah commit merge; graf bertambah padat
git bisect dan git blameLebih mudah — satu jalur lurusTetap bekerja, menelusuri parent dua
KonflikDiselesaikan per commit selama rebaseDiselesaikan sekali di commit merge

Dua baris terakhir tabel itu sering jadi penentu. Rebase menyelesaikan konflik berulang — sekali untuk setiap commit fitur yang bertabrakan — sementara merge menyelesaikannya sekali saja di akhir; perbandingan pengalaman menyelesaikan keduanya dibahas di chapter Rebase Conflicts .

Sebagai patokan praktis yang lazim: rebase untuk menjaga branch pribadi tetap segar terhadap main — sinkronisasi sesering mungkin, konflik dipecah kecil-kecil; merge untuk membawa fitur masuk ke main — satu titik integrasi yang tercatat jelas. Banyak tim memakai keduanya dalam satu hari, masing-masing pada perannya. Perdebatan lengkap dua aliran ini diulas Pro Git pada bab Git Branching – Rebasing .

Rebase pada chapter-chapter sebelumnya selalu memutar ulang commit apa adanya — kopian identik di basis baru. Padahal daftar todo bisa disunting: commit ditukar, digabung, diubah pesannya, dibuang. Editor yang membuka daftar itu bernama interactive rebase, dan itulah pintu masuk chapter berikutnya: Interactive Rebase .