Git on kenji.blog

【Perintah Git】Perbedaan antara rebase dan merge, serta penggunaan yang tepat dalam praktik

Sun, 13 Sep 2026 09:00:00 +0900

1. Pendahuluan: Mengapa “merge atau rebase” menjadi perdebatan abadi

Git adalah sistem pengontrol versi yang sangat penting dalam pengembangan perangkat lunak modern. Saat beberapa pengembang mengubah basis kode secara bersamaan, model cabang (branching) Git yang kuat akan sangat berguna. Namun, dalam pengembangan tim, perdebatan tentang “apakah harus menggunakan merge atau rebase” merupakan salah satu topik yang selalu membingungkan pengembang, mulai dari pemula hingga ahli.

Artikel ini akan mengupas perbedaan mekanisme antara git merge dan git rebase secara mendalam, mulai dari struktur internal Git yaitu DAG (Directed Acyclic Graph) dan sifat matematis dari hash komit. Selain itu, artikel ini juga akan menjelaskan secara menyeluruh bagaimana cara menggunakan keduanya secara tepat dalam praktik, disertai dengan alur kerja (workflow) yang konkret. Dengan memahami tidak hanya sekadar pengenalan perintah, tetapi juga perhitungan apa yang dilakukan Git di balik layar, Anda akan menghilangkan ketakutan terhadap konflik dan mampu membangun riwayat yang bersih serta mudah dilacak.

2. Struktur Internal Git: Hash Komit dan Model Objek

Untuk memahami bagaimana Git mengintegrasikan riwayat, pertama-tama kita perlu mengetahui bagaimana Git menyimpan data. Git tidak sekadar menyimpan perbedaan (patch) dari perubahan file, melainkan menyimpan cuplikan (snapshot) dari seluruh sistem file pada suatu titik waktu.

2.1 Sifat Kriptografi dari Hash Komit

Setiap komit Git diidentifikasi secara unik dengan 40 digit heksadesimal yang dihasilkan oleh fungsi hash SHA-1 (Secure Hash Algorithm 1) berdasarkan isinya. Objek komit terdiri dari elemen-elemen berikut:

Pointer ke objek Tree: Cuplikan struktur direktori dan file (Blob) pada saat itu.
Pointer ke komit induk (parent): Nilai hash dari satu atau lebih komit induk (komit pertama tidak memiliki induk, sedangkan komit merge memiliki dua induk atau lebih).
Informasi pembuat (Author): Orang yang menulis kode beserta tanggal dan waktunya.
Informasi committer (Committer): Orang yang membuat/menerapkan komit beserta tanggal dan waktunya.
Pesan komit: Teks yang menjelaskan maksud perubahan.

Secara matematis, nilai hash $H(C)$ untuk objek komit $C$ didefinisikan sebagai berikut:

$$ H(C) = \text{SHA-1}( \text{tree} \parallel \text{parent} \parallel \text{author} \parallel \text{committer} \parallel \text{message} ) $$

Di sini, $\parallel$ merepresentasikan penggabungan data. Karena karakteristik fungsi hash, meskipun hanya mengubah satu karakter pada pesan komit, atau jika komit induknya berbeda, nilai hash yang dihasilkan akan benar-benar berbeda. Artinya, komit bersifat tidak dapat diubah (Immutable). Alasan mengapa rebase yang akan dibahas nanti sering disebut “menulis ulang riwayat” sebenarnya adalah karena Git “membuat komit baru yang isinya mirip tetapi memiliki nilai hash yang berbeda”.

Ukuran ruang hash adalah $2^{160}$, dan probabilitas $P$ terjadinya tabrakan (dua komit berbeda memiliki nilai hash yang sama) dapat diaproksimasi menggunakan teori Paradoks Ulang Tahun (Birthday Paradox) sebagai berikut ($n$ adalah jumlah komit):

$$ P(\text{collision}) \approx 1 - \exp\left(-\frac{n^2}{2 \times 2^{160}}\right) $$

Probabilitas ini sangat rendah, sehingga secara praktis hampir tidak mungkin terjadi tabrakan hash komit pada Git.

3. Teori Graf dan DAG: Model Matematis Riwayat Git

Riwayat komit Git dimodelkan sebagai “Directed Acyclic Graph (DAG)” dalam teori graf.

3.1 Apa itu DAG (Directed Acyclic Graph)?

Dalam graf $G = (V, E)$, $V$ adalah himpunan komit (simpul/vertex), dan $E$ adalah himpunan edge berarah yang menunjukkan hubungan induk-anak antar komit. Pada Git, arah edge menuju dari “komit anak ke komit induk”. Hal ini karena komit baru menyimpan pointer ke komit sebelumnya.

graph BT
A["Komit A (Awal)"]
B["Komit B"]
C["Komit C (Main)"]
D["Komit D (Fitur)"]
E["Komit E (Merge)"]
B --> A
C --> B
D --> B
E --> C
E --> D

Fitur utama DAG adalah “tidak adanya siklus (putaran)”. Dengan ini, algoritma yang menelusuri riwayat komit tidak akan terjebak dalam loop tak terbatas, dan pasti akan mencapai titik akhir (komit awal).

3.2 Topological Sort dan Urutan Riwayat

Saat menampilkan riwayat menggunakan perintah git log, DAG diurutkan sebagai daftar 1 dimensi menggunakan algoritma Topological Sort (Pengurutan Topologi). Untuk setiap edge berarah $u \to v$ dalam DAG ($u$ adalah anak dari $v$), daftar disusun sedemikian rupa sehingga $u$ selalu berada sebelum $v$.

4. Mekanisme dan Jenis git merge

Perintah paling dasar untuk mengintegrasikan perubahan pada cabang adalah git merge. Namun, bergantung pada status saat ini, Git secara otomatis akan memilih strategi merge yang berbeda.

4.1 Merge Fast-Forward (–ff)

Jika cabang tujuan integrasi (misalnya: main) adalah leluhur langsung dari cabang sumber integrasi (misalnya: feature), Git akan menjalankan merge “Fast-Forward”. Ini adalah operasi yang tidak membuat komit baru, melainkan hanya memajukan pointer cabang ke depan.

gitGraph
commit id: "A"
commit id: "B"
branch feature
checkout feature
commit id: "C"
commit id: "D"
checkout main
merge feature

Merge Fast-Forward menjaga riwayat tetap dalam satu garis lurus, namun memiliki kelemahan yaitu hilangnya konteks “kelompok komit mana yang digabungkan sebagai satu pengembangan fitur (feature)”.

4.2 Merge Non-Fast-Forward (–no-ff)

Jika Anda secara eksplisit menentukan git merge --no-ff, Git akan selalu membuat “komit merge” baru meskipun situasi tersebut memungkinkan Fast-Forward. Komit merge adalah komit khusus yang memiliki dua induk.

gitGraph
commit id: "A"
commit id: "B"
branch feature
checkout feature
commit id: "C"
commit id: "D"
checkout main
commit id: "Main Work 1"
merge feature type: NORMAL

Keuntungan dari metode ini adalah bahwa keberadaan dan riwayat cabang fitur tetap terekam dengan jelas pada DAG. Saat terjadi masalah, Anda dapat membatalkan (revert) seluruh fitur sekaligus dengan aman dengan menjalankan git revert -m 1 <hash komit merge>.

4.3 Algoritma 3-Way Merge

Ketika cabang tujuan dan cabang sumber masing-masing memiliki komitnya sendiri, Git akan menjalankan 3-Way Merge (merge 3 arah). Pada saat ini, Git menelusuri DAG dan menemukan “leluhur umum (Lowest Common Ancestor, LCA)” dari kedua cabang tersebut.

Kompleksitas perhitungan algoritma untuk menemukan LCA, $T_{\text{LCA}}$, dapat dieksekusi dalam waktu linear terhadap jumlah simpul $|V|$ dan jumlah edge $|E|$:

$$ T_{\text{LCA}} = \mathcal{O}(|V| + |E|) $$

Git membandingkan tiga hal: “status LCA”, “status cabang saat ini”, dan “status cabang lawan”. Jika tidak ada konflik perubahan, Git secara otomatis akan menghasilkan komit merge.

5. Mekanisme git rebase dan Rekonstruksi Riwayat

Jika git merge “mengintegrasikan” riwayat, maka git rebase “merekonstruksi (memindahkan)” riwayat.

5.1 Pergerakan di Balik Rebase

Operasi internal saat melakukan rebase pada cabang feature ke cabang main (git rebase main) adalah sebagai berikut:

Menemukan leluhur umum (LCA) antara cabang feature dan cabang main.
Menyimpan sementara perbedaan komit dari LCA hingga ujung cabang feature.
Memindahkan pointer cabang feature ke ujung cabang main.
Menerapkan (Cherry-Pick) perbedaan yang disimpan tadi satu per satu secara berurutan ke atas base baru (ujung main), dan membuat komit baru.

graph TD
A["Komit A"] --> B["Komit B"]
B --> C["Komit C (Main)"]
B --> D["Komit D (Fitur Lama)"]
D -.-> E["Komit D' (Fitur Baru)"]
C --> E
style D stroke-dasharray: 5 5, fill: #f9f9f9, color: #999

Hal penting di sini adalah komit yang dihasilkan oleh rebase $D'$ memiliki induk komit yang berbeda dari komit aslinya $D$, sehingga memiliki nilai hash yang benar-benar berbeda (merujuk pada definisi fungsi hash $H(C)$ yang disebutkan sebelumnya).

5.2 Rebase Interaktif (Interactive Rebase)

Dengan menggunakan git rebase -i (atau --interactive), Anda dapat memanipulasi riwayat komit sesuka hati. Ini adalah alat paling ampuh untuk merapikan riwayat lokal.

pick : Menerima komit apa adanya
reword : Hanya mengubah pesan komit
edit : Menjeda untuk memodifikasi isi komit
squash : Menggabungkan komit ini dengan komit sebelumnya, dan juga menggabungkan pesannya
fixup : Sama seperti squash, tetapi membuang pesan dari komit ini
drop : Menghapus komit sepenuhnya

Secara matematis, jika sebuah cabang memiliki $N$ komit, variasi (permutasi) riwayat linear $P$ yang dapat dihasilkan dengan mengubah urutan rebase adalah sebagai berikut:

$$ P = N! $$

Git memberikan $N!$ macam kebebasan kepada pengembang, memungkinkan mereka untuk menjaga riwayat dalam kondisi yang logis dan indah.

6. Aturan Emas Rebase (The Golden Rule of Rebase)

rebase sangatlah kuat, namun terdapat satu aturan mutlak.

“Jangan pernah melakukan rebase pada riwayat publik yang telah dibagikan.” (Never rebase public history)

6.1 Mengapa Kita Tidak Boleh Melakukan Rebase pada Riwayat Publik?

Git bersifat terdistribusi. Komit yang Anda dorong (push) ke origin/main juga di-kloning (disalin) ke repositori lokal milik pengembang lain. Jika Anda merebase komit yang sudah di-push untuk menulis ulang riwayat, dan memaksakan penimpaan dengan git push --force, apa yang akan terjadi?

DAG lokal milik pengembang lain dan DAG jarak jauh (remote) akan bercabang secara mendasar. Ketika pengembang lain menjalankan git pull, Git akan mencoba memaksa penggabungan sekelompok komit yang memiliki sejarah berbeda. Hal ini akan menyebabkan banyak konflik dan komit duplikat (komit dengan perubahan yang sama tetapi hash yang berbeda), sehingga membuat repositori menjadi berantakan.

Aturan emasnya adalah rebase hanya boleh dilakukan pada “cabang lokal yang belum dibagikan kepada siapa pun”.

7. Penyelesaian Konflik dan git rebase –continue

Ketika beberapa orang mengubah bagian yang sama dari file yang sama, konflik akan terjadi. Proses penyelesaian konflik antara merge dan rebase berbeda.

7.1 Penyelesaian Konflik pada Merge

Pada git merge, penyelesaian konflik hanya terjadi satu kali. Sesaat sebelum membuat komit merge akhir, Anda memperbaiki semua bagian yang konflik sekaligus.

7.2 Penyelesaian Konflik pada Rebase

Pada git rebase, karena sifatnya yang menerapkan ulang komit satu per satu, ada kemungkinan konflik terjadi pada setiap komit.

Jika konflik terjadi selama rebase, Git akan menjeda prosesnya. Alur penyelesaiannya adalah sebagai berikut:

Buka editor atau IDE (seperti VS Code) dan perbaiki penanda konflik (seperti <<<<<<<, ======, >>>>>>>) secara manual.
Tambahkan file yang telah diperbaiki ke dalam indeks:
1

git add <file yang diperbaiki>
Tanpa membuat komit baru, lanjutkan proses rebase:
1

git rebase --continue

Jika Anda ingin membatalkan rebase itu sendiri dan kembali ke keadaan semula, jalankan perintah berikut:

1

git rebase --abort

（Jika penyelesaian konflik tidak diperlukan dan Anda ingin melewati komit tersebut, gunakan git rebase --skip)

8. Penggunaan yang Tepat dalam Praktik (Praktik Workflow)

Lalu, bagaimana sebaiknya kita menggunakan merge dan rebase dalam praktik pengembangan yang sebenarnya? Di sini kita akan memperkenalkan pendekatan yang paling standar dan aman.

8.1 【Skenario 1】 Merapikan Riwayat Pekerjaan Lokal (Menggunakan Rebase)

Misalkan saat mengembangkan di cabang fitur, banyak komit kecil menumpuk (seperti “Perbaikan typo” atau “Simpan sementara”). Sebelum membuat Pull Request (PR), gunakan rebase interaktif untuk merapikannya ke dalam unit-unit yang bermakna.

1
2
3


# Jalankan saat berada di cabang feature
git rebase -i HEAD~5
# (Editor akan terbuka, gunakan squash atau fixup untuk membersihkan riwayat)

Dengan melakukan ini, Anda dapat membuat riwayat komit yang indah dan maksudnya mudah dipahami oleh pengulas (reviewer).

8.2 【Skenario 2】 Mengikuti Pembaruan Cabang main Terbaru (Menggunakan Rebase)

Jika pengembangan memakan waktu lama dan perubahan dari orang lain terus menerus di-merge ke cabang main, cabang feature milik Anda akan menjadi usang. Dalam kasus ini, lakukan rebase cabang feature Anda ke cabang main terbaru agar tetap sinkron.

1
2
3
4
5


# Dapatkan informasi terbaru dari main
git fetch origin

# Pindahkan cabang feature ke atas main terbaru
git rebase origin/main

Dengan cara ini, riwayat menjadi satu garis lurus dan dapat mencegah konflik pada merge selanjutnya. Selain itu, Anda juga mencegah pembuatan komit merge yang tidak perlu (seperti “Merge branch ‘main’ into feature”).

8.3 【Skenario 3】 Mengintegrasikan Fitur yang Telah Selesai (Menggunakan Merge)

Pengembangan pada cabang feature telah selesai, dan sekarang saatnya memasuki fase integrasi ke cabang main. Di sini kita menggunakan git merge --no-ff (sama seperti memilih “Create a merge commit” di Pull Request pada GitHub, dll.).

1
2
3


git checkout main
git merge --no-ff feature -m "Merge feature: Implementasi fitur login pengguna"
git push origin main

Dengan ini, sebuah titik sejarah (komit merge) yang menunjukkan “satu fitur digabungkan di sini” akan tertinggal pada DAG cabang main. Saat Anda melihat riwayat di kemudian hari, akan lebih mudah untuk menelusuri kode berdasarkan unit fitur.

9. Kesimpulan (Ringkasan)

Dalam pengoperasian Git, pendekatan ekstrem seperti “selesaikan semuanya dengan Merge” atau “buat semuanya lurus dengan Rebase” masing-masing memiliki kelebihan dan kekurangan.

Praktik terbaik (best practice) dalam bekerja adalah pendekatan hibrida: “Rapikan riwayat pribadi lokal dengan rebase, dan pertahankan konteks riwayat integrasi publik menggunakan merge –no-ff.”

Lokal (Ruang Kerja Pribadi): Gunakan rebase untuk membuang komit yang tidak perlu dan mengikuti mainline terbaru agar riwayat tetap lurus.
Global (Ruang Kerja Bersama): Gunakan merge --no-ff untuk mencatat keberadaan cabang fitur sebagai komit merge pada DAG, sehingga memudahkan revert dan pelacakan.

Dengan memahami latar belakang matematis dan arsitektural, seperti struktur DAG dan mekanisme fungsi hash, perintah Git akan meningkat dari sekadar hafalan menjadi “desain riwayat yang memiliki tujuan”. Sambil mematuhi aturan emas rebase, pilihlah perintah yang paling tepat sesuai situasi untuk membangun riwayat komit yang bersih, mudah dibaca, dan mudah dipelihara bagi seluruh tim.

Kumpulan Kesalahan Pemula Git dan Perintah Solusinya (Mengatasi Konflik, dll.)

Sat, 12 Sep 2026 17:00:00 +0900

Kumpulan Kesalahan Pemula Git dan Perintah Solusinya (Mengatasi Konflik, dll.)

1. Pendahuluan: Mengapa Kita Melakukan Kesalahan di Git?

Dalam pengembangan perangkat lunak, Git telah menjadi hal yang sangat penting seperti udara atau air. Namun, bagi banyak pemula (dan bahkan terkadang bagi para ahli), Git bisa terasa seperti “kotak hitam ajaib yang menakutkan”. Komit yang menghilang, mendorong banyak perubahan ke cabang yang salah secara tidak sengaja, atau pesan kesalahan konflik yang belum pernah dilihat sebelumnya memenuhi layar… Saat terjebak dalam “perangkap Git” ini, progres pekerjaan bisa terhenti sepenuhnya, dan dalam skenario terburuk, muncul ketakutan bahwa kode sumber mungkin akan hancur.

Mengapa Git begitu sulit dan memicu kesalahan? Alasan utamanya adalah “kita menggunakannya dengan hanya menghafal perintah tanpa memahami apa yang terjadi di dalam Git”. Git dibangun berdasarkan filosofi desain yang kuat sebagai sistem kontrol versi terdistribusi (DVCS), namun antarmukanya (CLI) tidak selalu intuitif.

Artikel ini mengklasifikasikan berbagai “kesalahan umum” yang sering dihadapi oleh pemula Git di lapangan ke dalam berbagai kasus, dan menyajikan perintah sebagai solusi spesifik untuk masing-masing kasus. Namun, ini tidak akan menjadi sekadar daftar perintah (cheat sheet). Kami akan menggali lebih dalam dengan menjelaskan “mengapa kesalahan itu terjadi” dan “bagaimana data bergerak di dalam Git saat perintah tersebut dijalankan”, menggunakan struktur direktori .git, latar belakang matematis dari algoritma Diff yang berjalan di belakangnya, dan diagram Mermaid. Semuanya akan dibahas tuntas dalam lebih dari 10.000 karakter.

Pada saat Anda selesai membaca artikel ini, Anda seharusnya dapat melepaskan diri dari perasaan “takut pada Git”, dan sebaliknya, Anda akan yakin bahwa “tidak ada rekan yang lebih bisa diandalkan daripada Git”. Sekarang, mari kita terjun ke dunia Git yang mendalam.

2. Jurang Git: Memahami Struktur Internal Direktori `.git`

Langkah pertama untuk mempermudah pemecahan masalah adalah mengetahui bagaimana Git menyimpan data. Folder tersembunyi .git yang ada di direktori root proyek Anda adalah jantung dari Git. Git bukanlah sistem yang hanya merekam perbedaan file (patch) secara berurutan, melainkan mengelola data sebagai aliran snapshot (snapshot stream).

2.1 Model Objek: Blob, Tree, Commit

Git pada dasarnya menggunakan 3 objek untuk merepresentasikan keadaan repositori. Objek-objek ini disimpan di .git/objects.

Blob (Binary Large Object) Objek ini menyimpan isi file itu sendiri. Informasi tentang nama file atau izin tidak disertakan di sini. Urutan byte murni dikompresi dengan zlib dan diidentifikasi oleh nilai hash SHA-1 (40 karakter heksadesimal).
Tree Objek ini merepresentasikan struktur direktori. Objek Tree berisi pointer (nilai hash SHA-1) ke objek Tree lainnya (subdirektori) atau objek Blob (file), beserta nama file dan izin aksesnya. Ini berfungsi mirip dengan direktori pada UNIX.
Commit Menyimpan pointer ke objek Tree tingkat atas (top-level) dari seluruh repositori pada titik waktu tertentu, bersama dengan metadata (pembuat, tanggal dan waktu komit, pesan komit), dan pointer ke komit sebelumnya (komit induk).

graph TD
Commit1["Komit (Hash: 9f8a)"] --> Tree1["Tree (Hash: 4b82)"]
Tree1 --> Blob1["Blob (Hash: 8d7e) : index.js"]
Tree1 --> Tree2["Tree (Hash: 3a2c) : src/"]
Tree2 --> Blob2["Blob (Hash: 5f1b) : app.js"]

2.2 Identitas Asli HEAD dan Referensi (Refs)

Saat bekerja dengan Git, Anda akan sering melihat kata HEAD. Ini adalah referensi simbolik (Symbolic Reference) yang menunjuk ke cabang (atau komit) yang sedang di-checkout saat ini. Jika Anda membuka file .git/HEAD dengan teks editor, Anda akan melihat string seperti berikut:

1

ref: refs/heads/main

Ini berarti “keadaan saat ini berada di ujung cabang main”. Dan, jika Anda membuka .git/refs/heads/main, Anda akan melihat hash SHA-1 sebanyak 40 karakter tertulis di sana, yang menunjuk ke objek Commit terbaru. Cabang Git hanyalah pointer ringan (file) yang menunjuk ke komit tertentu. Hanya dengan mengetahui fakta ini, ketakutan bahwa “jika saya menghapus cabang, apakah semua file akan hilang?” akan sirna.

3. Mengartikan Git dengan Matematika: Algoritma Diff dan Fungsi Hash

Ketika Git mendeteksi konflik atau menampilkan perbedaan pada file, algoritma tingkat lanjut sedang berjalan di latar belakang.

3.1 Algoritma Diff Myers

Algoritma pendeteksi perbedaan default pada Git adalah algoritma yang dirancang oleh Eugene W. Myers. Ketika ada dua file teks $A$ dan $B$, masalah untuk menemukan “urutan pengeditan minimum (penyisipan dan penghapusan)” untuk mengubah $A$ menjadi $B$ dapat dimodelkan sebagai masalah jalur terpendek dalam teori graf.

Misalkan panjang string masing-masing adalah $N$ dan $M$, dan totalnya adalah $V = N + M$. Dalam algoritma Myers, pencarian Jarak Edit (Edit Distance) $D$ dilakukan. Kompleksitas waktu algoritma ini dinyatakan dengan rumus berikut:

$$ \mathcal{O}(V \cdot D) $$

Di sini, jika perbedaan antar file kecil (artinya $D$ kecil), algoritma bekerja sangat cepat dengan $\mathcal{O}(V)$. Namun, jika filenya benar-benar berbeda, $D \approx V$, dan kompleksitas terburuknya menjadi $\mathcal{O}(V^2)$.

3.2 Patience Diff dan Histogram Diff

Meskipun algoritma Myers sangat baik, terkadang dapat menghasilkan perbedaan yang tidak intuitif (tidak bermakna) bagi manusia, misalnya ketika urutan fungsi atau kelas diubah secara signifikan. Untuk mengatasi hal ini, Git mengimplementasikan Patience Diff dan Histogram Diff.

Patience Diff berfokus pada “baris unik yang muncul hanya sekali di kedua file”, dan menemukan Urutan Bagian Terpanjang Bersama (Longest Common Subsequence: LCS) dari baris-baris tersebut. Jika jumlah elemen unik adalah $U$, perhitungan LCS dapat diselesaikan dengan kompleksitas berikut:

$$ \mathcal{O}(U \log U) $$

Ketika Anda merasa sulit untuk menyelesaikan konflik, salah satu pendekatannya adalah dengan menggunakan git diff --histogram atau menentukan algoritma ini dalam strategi penggabungan (merge) (git merge -s recursive -X histogram).

3.3 SHA-1 dan Probabilitas Tabrakan

Git mengelola semua objek menggunakan nilai hash SHA-1. Ukuran ruang hash adalah $2^{160}$. Mengenai probabilitas tabrakan hash (di mana konten yang berbeda memiliki nilai hash yang sama), jika diperkirakan menggunakan Paradoks Ulang Tahun (Birthday Paradox), jumlah objek $k$ yang dibutuhkan agar probabilitas tabrakan $p$ menjadi 50% adalah sebagai berikut:

$$ k \approx \sqrt{2 \ln(2)} \cdot 2^{80} \approx 1.2 \times 2^{80} $$

Ini adalah angka astronomis, dan probabilitas tabrakan yang tidak disengaja terjadi dalam pengembangan perangkat lunak pada umumnya hampir nol. Oleh karena itu, Git beroperasi dengan mempercayai nilai hash sebagai “ID unik yang mutlak”.

4. Studi Kasus 1: Saya Melakukan Komit ke Cabang yang Salah!

[Situasi] Tanpa sadar bahwa saya sedang bekerja di cabang main, saya menulis banyak kode untuk fitur baru, dan bahkan menjalankan git commit. Padahal seharusnya saya membuat cabang feature/login dan bekerja di sana!

Solusi: `git reset` dan Membuat Cabang Baru

Dalam Git, komit adalah objek independen, dan cabang hanyalah pointer. Oleh karena itu, Anda dapat langsung menyelesaikannya dengan operasi: “buat cabang baru, lalu mundurkan pointer dari cabang saat ini”.

1
2
3
4
5
6
7
8
9


# 1. Buat cabang baru yang menunjuk ke komit saat ini (komit yang dibuat secara tidak sengaja)
$ git branch feature/login

# 2. Mundurkan pointer cabang main ke satu komit sebelumnya (HEAD~1)
# Menggunakan --keep memungkinkan Anda melakukan reset dengan aman sambil mempertahankan perubahan yang belum dikomit di direktori kerja Anda.
$ git reset --keep HEAD~1

# 3. Beralih ke cabang yang benar
$ git checkout feature/login

Penjelasan Gambar: Apa yang Terjadi di Dalam?

Mari kita visualisasikan pergerakan pointer cabang pada saat ini menggunakan gitGraph dari Mermaid.

gitGraph
commit id: "Komit awal"
commit id: "Perbaikan bug"
commit id: "Komit yang Salah" type: HIGHLIGHT
branch feature/login
checkout feature/login
checkout main

Pada awalnya, main dan HEAD menunjuk ke “Komit yang Salah”, tetapi git branch feature/login membuat pointer baru di sana. Setelah itu, karena git reset, hanya pointer main yang kembali ke posisi “Perbaikan bug”. Objeknya sendiri tidak ada yang dihapus.

5. Studi Kasus 2: Saya Ingin Membatalkan Komit yang Sudah Di-push!

[Situasi] Mengerjakan koding larut malam membuat saya mengkomit kode yang penuh bug, dan bahkan mempublikasikannya ke repositori jarak jauh (remote) dengan git push origin main. Saya menjadi panik saat menyadari adanya bug kritis.

Solusi 1: Membatalkan Sejarah dengan `git revert` (Disarankan / Aman)

Dalam pengembangan tim, sangat dilarang untuk mengubah riwayat komit yang sudah di-push menggunakan perintah seperti git reset. Ini akan menyebabkan inkonsistensi dengan repositori lokal pengembang lain. Pendekatan yang benar adalah “membuat komit baru yang sepenuhnya membatalkan perubahan dari komit yang salah”. Ini adalah fungsi dari git revert.

1
2
3
4
5
6
7


# Buat komit yang membatalkan komit terbaru
$ git revert HEAD
[main 7f3a8b2] Revert "Pesan komit yang salah"
 1 file changed, 1 insertion(+), 10 deletions(-)

# Push ke remote
$ git push origin main

gitGraph
commit id: "Komit A"
commit id: "Komit B (Salah)"
commit id: "Revert Komit B" type: REVERSE

Sejarah terus berlanjut, dan hanya status kodenya yang dikembalikan ke keadaan semula.

Solusi 2: Mengubah Sejarah dengan `git push --force-with-lease`

Jika Anda baru saja melakukan push ke cabang yang hanya digunakan oleh Anda sendiri, maka mengubah riwayat dapat ditoleransi.

1
2
3
4
5
6
7


# Reset komit secara lokal dan perbaiki
$ git reset --hard HEAD~1
$ git add .
$ git commit -m "Correct implementation"

# Timpa riwayat jarak jauh secara paksa
$ git push origin feature/login --force-with-lease

--force-with-lease adalah push paksa yang aman untuk mencegah kecelakaan di mana Anda secara tidak sengaja menimpa pekerjaan orang lain.

6. Studi Kasus 3: Saya Ingin Beralih ke Cabang Lain Saat Sedang Bekerja (Keajaiban Stash)

[Situasi] Sedang mengimplementasikan fitur baru di cabang feature/A, kode sumbernya masih berantakan dan belum bisa dikompilasi. Tiba-tiba atasan memberi instruksi: “Ada bug darurat di lingkungan produksi cabang main, tolong perbaiki sekarang juga!”

Solusi: Menyimpan Sementara dengan `git stash`

git stash adalah perintah untuk menyimpan sementara perubahan yang belum dikomit ke area sementara.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12


# 1. Simpan perubahan yang sedang dikerjakan
$ git stash push -m "WIP: feature A partially implemented"

# 2. Sekarang Anda dapat beralih ke cabang main
$ git checkout main
# ...(melakukan perbaikan bug darurat, commit, dan push)...

# 3. Setelah pekerjaan selesai, kembali ke cabang semula
$ git checkout feature/A

# 4. Pulihkan perubahan yang telah disimpan
$ git stash pop

Ketika git stash dijalankan, Git secara internal menghasilkan dua objek komit khusus dan menyimpannya di referensi bernama refs/stash. Artinya, Stash pada dasarnya juga merupakan “komit sementara yang tidak memiliki nama”.

7. Studi Kasus 4: Keadaan Mengerikan “Detached HEAD”

[Situasi] Saya ingin memeriksa kode pada titik waktu tertentu di masa lalu, jadi saya menjalankan git checkout 9f8a7b6. Kemudian muncul pesan You are in 'detached HEAD' state.. Saya tetap melakukan komit, tetapi setelah berpindah cabang, komit tersebut menghilang!

Mekanisme Detached HEAD

Biasanya HEAD menunjuk ke cabang seperti refs/heads/main. Namun, jika Anda melakukan checkout pada komit tertentu secara langsung, HEAD akan menunjuk langsung ke objek komit tersebut. Ini disebut Detached HEAD (HEAD yang terpisah).

graph TD
A["Komit A"] --> B["Komit B"]
B --> C["Komit C"]
C --> D["Komit D"]
BranchMain["Cabang: main"] --> D
HEAD["HEAD"] --> B
style HEAD fill:#f9f,stroke:#333,stroke-width:4px

Dalam keadaan ini, jika Anda menambahkan komit, tidak ada cabang yang akan melacak komit baru tersebut. Saat Anda beralih ke cabang lain, komit baru itu akan tersesat.

Solusi: Simpan Sebagai Cabang Baru

Anda dapat menyelesaikannya dengan membuat cabang baru di posisi Anda saat ini.

1
2


# Buat cabang baru di posisi HEAD saat ini dan beralih ke cabang tersebut
$ git checkout -b feature/recovered-work

8. Studi Kasus 5: Menyelesaikan Konflik Saat Merge dan Rebase

[Situasi] Saat menjalankan git merge atau git rebase, muncul pesan CONFLICT (content), dan proses dihentikan.

Perbedaan Antara Merge (Penggabungan) dan Rebase (Penyusunan Ulang)

Merge (Penggabungan) Melakukan 3-way merge menggunakan komit terbaru dari kedua cabang dan leluhur bersamanya (common ancestor), serta membuat komit gabungan (merge commit).
Rebase (Penyusunan Ulang) Menyimpan sementara komit dari cabang saat ini, lalu menerapkannya kembali di ujung target. Riwayatnya akan menjadi satu garis lurus.

gitGraph
commit id: "M1"
commit id: "M2"
branch feature
checkout feature
commit id: "F1"
commit id: "F2"
checkout main
commit id: "M3"
merge feature

Cara Menyelesaikan Konflik

Penanda berikut akan disisipkan dalam file yang mengalami konflik.

1
2
3
4
5


<<<<<<< HEAD
const apiUrl = "https://api.production.example.com";
=======
const apiUrl = "https://api.staging.example.com";
>>>>>>> feature/new-api

Langkah penyelesaiannya sangat sederhana.

Hapus penanda dan perbaiki kodenya.

1
2
3


const apiUrl = process.env.NODE_ENV === 'production'
 ? "https://api.production.example.com"
 : "https://api.staging.example.com";

Tambahkan file yang sudah diperbaiki ke staging. git add memiliki peran “memberitahu Git bahwa konflik telah diselesaikan”.
1

$ git add index.js

Selesaikan prosesnya.

1
2
3
4
5


# Untuk merge
$ git commit -m "Resolve merge conflict in index.js"

# Untuk rebase
$ git rebase --continue

Jika panik, Anda bisa membatalkannya kapan saja dengan $ git merge --abort atau $ git rebase --abort.

9. Studi Kasus 6: Riwayat Komit Berantakan! `git rebase -i`

[Situasi] “Perbaikan typo”, “perbaikan lagi”, “tambah tes”, dan banyak komit kecil lainnya terkumpul. Jika di-merge ke main seperti ini, riwayatnya akan terlihat kotor.

Solusi: Interactive Rebase (Rebase Interaktif)

Dengan menggunakan git rebase -i (interactive), Anda dapat mengubah urutan komit sebelumnya, menggabungkan beberapa komit menjadi satu (squash), atau mengubah pesan komit.

1
2


# Rapikan 3 komit terakhir
$ git rebase -i HEAD~3

Editor akan terbuka dan menampilkan hal berikut:

1
2
3


pick 1a2b3c4 Perbaikan typo
pick 2b3c4d5 Perbaikan lagi
pick 3c4d5e6 Tambah tes

Ubah ini menjadi seperti berikut:

1
2
3


pick 1a2b3c4 Implementasi Fitur X
squash 2b3c4d5 Perbaikan lagi
squash 3c4d5e6 Tambah tes

Setelah disimpan dan ditutup, ketiga komit ini akan digabungkan menjadi satu dengan rapi.

10. Studi Kasus 7: Tidak Tahu Kapan Bug Masuk! `git bisect`

[Situasi] Terdapat bug pada cabang main saat ini, namun saat rilis sebulan yang lalu semuanya normal. Saya ingin mencari komit mana yang memasukkan bug tersebut, tetapi ada lebih dari 100 komit sehingga tidak mungkin dilakukan secara manual!

Solusi: Identifikasi Bug dengan Pencarian Biner

Git memiliki alat bawaan untuk menemukan komit penyebab bug dengan menggunakan pencarian biner matematis (Binary Search). Karena kompleksitasnya adalah $\mathcal{O}(\log N)$, meskipun ada 1000 komit, ia dapat mengidentifikasinya hanya dalam sekitar 10 pengujian.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14


# Mulai pencarian
$ git bisect start

# Komit saat ini mengandung bug (bad)
$ git bisect bad

# Sebulan lalu (misalnya hash a1b2c3d) masih normal (good)
$ git bisect good a1b2c3d

# Git akan secara otomatis men-checkout komit di tengah-tengah, lalu jalankan pengujian
# Jika tes berhasil:
$ git bisect good
# Jika tes gagal:
$ git bisect bad

Dengan mengulangi ini, Git akan memberi tahu Anda dengan tepat, “Ini adalah komit Bad yang pertama”. Setelah selesai, kembalikan ke status awal dengan $ git bisect reset.

11. Jaring Pengaman Utama: `git reflog`

Jurus rahasia terakhir untuk mengatasi segala “kesalahan” di Git adalah git reflog. Git mencatat semua riwayat operasi lokal (riwayat pergerakan HEAD) selama periode tertentu. Bahkan jika Anda menghapus cabang atau melakukan reset yang salah, Anda dapat menemukan hash sebelumnya dengan git reflog dan memulihkannya hanya dengan melakukan git reset --hard ke hash tersebut.

1
2
3


$ git reflog
9f8a7b6 (HEAD -> main) HEAD@{0}: commit: Add new feature
1a2b3c4 HEAD@{1}: reset: moving to HEAD~1

12. Penutup

Kami telah menjelaskan secara sangat rinci kesalahan yang sering dilakukan oleh pemula Git, mekanisme Git di baliknya, dan cara mengatasinya. Mulai dari melakukan komit ke cabang yang salah, membatalkan komit yang sudah di-push, memanfaatkan Stash, selamat dari Detached HEAD, hingga menyelesaikan konflik. Yang paling penting dalam semua hal ini adalah membayangkan “objek dan pointer apa yang sedang dimanipulasi Git di latar belakang”.

Perbedaan file dihitung menggunakan algoritma Diff yang ketat yang dapat direpresentasikan oleh rumus matematika, dan konsistensi riwayat dijamin oleh fungsi hash kriptografi. Jika Anda memahami filosofi desain yang indah ini, Anda akan menyadari bahwa Git bukanlah “kotak hitam misterius”, melainkan perisai terkuat untuk melindungi kode sumber Anda dengan kuat.

Lain kali Anda berpikir, “Oh tidak, saya mengacaukannya!”, jangan panik lalu menutup terminal. Tariklah napas dalam-dalam dan ketik git status. Git pasti akan memberi Anda petunjuk untuk pemulihan.

Git on kenji.blog

【Perintah Git】Perbedaan antara rebase dan merge, serta penggunaan yang tepat dalam praktik

1. Pendahuluan: Mengapa “merge atau rebase” menjadi perdebatan abadi

2. Struktur Internal Git: Hash Komit dan Model Objek

2.1 Sifat Kriptografi dari Hash Komit

3. Teori Graf dan DAG: Model Matematis Riwayat Git

3.1 Apa itu DAG (Directed Acyclic Graph)?

3.2 Topological Sort dan Urutan Riwayat

4. Mekanisme dan Jenis git merge

4.1 Merge Fast-Forward (–ff)

4.2 Merge Non-Fast-Forward (–no-ff)

4.3 Algoritma 3-Way Merge

5. Mekanisme git rebase dan Rekonstruksi Riwayat

5.1 Pergerakan di Balik Rebase

5.2 Rebase Interaktif (Interactive Rebase)

6. Aturan Emas Rebase (The Golden Rule of Rebase)

6.1 Mengapa Kita Tidak Boleh Melakukan Rebase pada Riwayat Publik?

7. Penyelesaian Konflik dan git rebase –continue

7.1 Penyelesaian Konflik pada Merge

7.2 Penyelesaian Konflik pada Rebase

8. Penggunaan yang Tepat dalam Praktik (Praktik Workflow)

8.1 【Skenario 1】 Merapikan Riwayat Pekerjaan Lokal (Menggunakan Rebase)

8.2 【Skenario 2】 Mengikuti Pembaruan Cabang main Terbaru (Menggunakan Rebase)

8.3 【Skenario 3】 Mengintegrasikan Fitur yang Telah Selesai (Menggunakan Merge)

9. Kesimpulan (Ringkasan)

Kumpulan Kesalahan Pemula Git dan Perintah Solusinya (Mengatasi Konflik, dll.)

Kumpulan Kesalahan Pemula Git dan Perintah Solusinya (Mengatasi Konflik, dll.)

1. Pendahuluan: Mengapa Kita Melakukan Kesalahan di Git?

2. Jurang Git: Memahami Struktur Internal Direktori .git

2.1 Model Objek: Blob, Tree, Commit

2.2 Identitas Asli HEAD dan Referensi (Refs)

3. Mengartikan Git dengan Matematika: Algoritma Diff dan Fungsi Hash

3.1 Algoritma Diff Myers

3.2 Patience Diff dan Histogram Diff

3.3 SHA-1 dan Probabilitas Tabrakan

4. Studi Kasus 1: Saya Melakukan Komit ke Cabang yang Salah!

Solusi: git reset dan Membuat Cabang Baru

Penjelasan Gambar: Apa yang Terjadi di Dalam?

5. Studi Kasus 2: Saya Ingin Membatalkan Komit yang Sudah Di-push!

Solusi 1: Membatalkan Sejarah dengan git revert (Disarankan / Aman)

Solusi 2: Mengubah Sejarah dengan git push --force-with-lease

6. Studi Kasus 3: Saya Ingin Beralih ke Cabang Lain Saat Sedang Bekerja (Keajaiban Stash)

Solusi: Menyimpan Sementara dengan git stash

7. Studi Kasus 4: Keadaan Mengerikan “Detached HEAD”

Mekanisme Detached HEAD

Solusi: Simpan Sebagai Cabang Baru

8. Studi Kasus 5: Menyelesaikan Konflik Saat Merge dan Rebase

Perbedaan Antara Merge (Penggabungan) dan Rebase (Penyusunan Ulang)

Cara Menyelesaikan Konflik

9. Studi Kasus 6: Riwayat Komit Berantakan! git rebase -i

Solusi: Interactive Rebase (Rebase Interaktif)

10. Studi Kasus 7: Tidak Tahu Kapan Bug Masuk! git bisect

Solusi: Identifikasi Bug dengan Pencarian Biner

11. Jaring Pengaman Utama: git reflog

12. Penutup

2. Jurang Git: Memahami Struktur Internal Direktori `.git`

Solusi: `git reset` dan Membuat Cabang Baru

Solusi 1: Membatalkan Sejarah dengan `git revert` (Disarankan / Aman)

Solusi 2: Mengubah Sejarah dengan `git push --force-with-lease`

Solusi: Menyimpan Sementara dengan `git stash`

9. Studi Kasus 6: Riwayat Komit Berantakan! `git rebase -i`

10. Studi Kasus 7: Tidak Tahu Kapan Bug Masuk! `git bisect`

11. Jaring Pengaman Utama: `git reflog`