- Bab 5 dari 8
- 35 menit
- 4 soal kuis
Branch, Pull Request, dan Code Review
Di bab ini (9 bagian)
Tujuan bab ini
- Membuat branch di GitHub dan di laptop, lalu membuka pull request dengan base dan compare yang benar.
- Menulis PR yang enak di-review: judul jelas, deskripsi lengkap, draft bila belum siap, dan
Closes #12. - Melakukan code review: komentar per baris, suggestion, lalu Approve atau Request changes.
- Memilih strategi merge yang tepat dan menyelesaikan merge conflict di GitHub maupun di laptop.
Branch di GitHub
Branch adalah jalur kerja terpisah dari main. Kamu bisa bereksperimen di sana tanpa mengganggu kode yang sudah jalan. Cara bikinnya ada dua:
- Di github.com: di halaman repo, klik menu branch (tulisannya
main), ketik nama baru sepertifeature/login, lalu pilih Create branch feature/login from main. Semua branch bisa dilihat di halaman Branches. - Di laptop (detailnya ada di kelas Git):
Pakai nama yang menjelaskan tujuan: feature/… untuk fitur, bugfix/… untuk perbaikan bug, hotfix/… untuk perbaikan darurat. Prinsipnya: satu branch, satu tujuan, umurnya pendek.
Membuat pull request
Pull request (PR) adalah cara resmi bilang "tolong cek perubahanku, lalu gabungkan ke main". Setelah kamu push branch, GitHub biasanya menampilkan banner Compare & pull request. Bisa juga lewat tab Pull requests → New pull request.
Dua pilihan di atas form PR wajib kamu cek:
- base: branch tujuan, tempat perubahan akan digabung (biasanya
main). - compare: branch sumber yang berisi perubahanmu (misalnya
feature/login).
Kebalik sedikit saja, PR-mu malah mengusulkan isi main masuk ke branch fitur.
Lalu isi judul yang menjelaskan hasil, misalnya "Tambah validasi form login", bukan "update". Di deskripsi, tulis apa yang berubah, kenapa, dan cara mengetesnya. Tambahkan screenshot kalau ada perubahan tampilan.
Baris Closes #12 menautkan PR ke issue nomor 12. Begitu PR di-merge ke branch default, issue itu otomatis tertutup. Kata kunci lain yang dikenali: Fixes dan Resolves, termasuk variasi close, fixed, atau resolved.
Belum selesai tapi mau minta masukan awal? Klik panah di samping tombol Create pull request, lalu pilih Create draft pull request. Draft PR tidak bisa di-merge dan tidak meminta review dari code owner secara otomatis. Kalau sudah siap, klik Ready for review.
Setelah PR dibuat, pilih Reviewers di sidebar kanan. PR itu "hidup": setiap push baru ke branch yang sama langsung memperbarui PR, jadi kamu tidak perlu membuat PR baru untuk memperbaiki masukan.
Code review
Reviewer bekerja di tab Files changed. Baris merah adalah yang dihapus, baris hijau yang ditambahkan.
- Komentar baris: arahkan kursor ke sebuah baris, klik ikon + biru, lalu tulis komentar. Kamu bisa drag untuk memilih beberapa baris sekaligus.
- Suggestion: di kotak komentar, klik ikon Insert a suggestion. GitHub menyiapkan blok seperti ini, isinya kamu ganti dengan kode usulan:
Penulis PR bisa langsung klik Commit suggestion, atau mengumpulkan beberapa saran dengan Add suggestion to batch lalu meng-commit semuanya sekaligus.
- Add single comment mengirim komentar saat itu juga. Start a review mengumpulkan komentar dulu dan baru dikirim saat review diselesaikan.
Untuk menyelesaikan review, klik Review changes, tulis ringkasan, lalu pilih satu:
| Pilihan | Arti |
|---|---|
| Comment | memberi masukan tanpa menyetujui atau menolak |
| Approve | perubahan layak digabung |
| Request changes | harus diperbaiki dulu sebelum merge |
Etika review: kritik kodenya, bukan orangnya. Jelaskan alasan, bedakan saran wajib dan selera pribadi, dan jangan lupa memuji bagian yang bagus.
Tiga strategi merge
Tombol hijau di bawah PR punya panah dropdown dengan tiga pilihan. Hasil riwayatnya beda:
| Strategi | Yang terjadi di main | Plus | Minus |
|---|---|---|---|
| Create a merge commit | semua commit branch masuk, plus satu merge commit | riwayat lengkap | grafik jadi ramai |
| Squash and merge | semua commit dipadatkan jadi satu commit baru | main rapi, satu PR satu commit | detail commit kecil hilang |
| Rebase and merge | commit branch ditaruh ulang di ujung main tanpa merge commit | riwayat lurus | hash commit berubah |
Squash and merge paling umum di tim kecil, karena judul commit-nya otomatis memakai judul PR plus nomornya, misalnya Tambah validasi form login (#42). Pemilik repo bisa mematikan strategi tertentu di Settings → General, bagian Pull Requests. Setelah merge, klik Delete branch supaya daftar branch tetap bersih.
Merge conflict
Konflik muncul saat dua branch mengubah baris yang sama di file yang sama. GitHub akan menulis This branch has conflicts that must be resolved, dan tombol merge tidak bisa diklik.
Di GitHub (editor web): untuk konflik sederhana, klik Resolve conflicts. File muncul dengan penanda konflik. Edit sampai tersisa versi final, hapus semua penanda, klik Mark as resolved, lalu Commit merge. Konflik yang lebih rumit, misalnya file dihapus di satu sisi, harus diselesaikan di laptop.
Di laptop: gabungkan main ke branch-mu, lalu bereskan konflik di editor.
Bagian atas ======= adalah versi branch aktif (HEAD), bagian bawah versi yang masuk dari main. Pilih salah satu atau gabungkan keduanya, hapus ketiga penanda, lalu:
PR di GitHub langsung terupdate dan tombol merge aktif lagi. VS Code juga punya tombol Accept Current Change, Accept Incoming Change, dan Accept Both Changes untuk mempercepat.
Kesalahan umum
- Base dan compare tertukar. Selalu baca kalimat ringkas di atas PR: branch mana digabung ke mana.
- PR raksasa. Lima puluh file sekaligus bikin reviewer pusing. Pecah jadi beberapa PR kecil.
- Penanda konflik ikut ter-commit. Cari
<<<<<<<sebelum commit. git branch -dgagal setelah squash merge. Git bilangnot fully mergedkarena commit aslinya memang tidak ada dimain. Kalau PR sudah di-merge, hapus dengangit branch -D.- Push ke branch lain untuk memperbaiki review. Push ke branch yang sama supaya PR ikut terupdate.
Coba sendiri
Simulasikan konflik dan squash di laptop. Hash di laptopmu akan berbeda.
Bereskan, lalu coba squash:
Dua commit footer menjadi satu commit, persis seperti Squash and merge di GitHub.
Rangkuman
- PR menggabungkan branch compare ke branch base; tulis judul jelas, deskripsi lengkap, dan
Closes #12untuk menutup issue otomatis. - Draft PR untuk pekerjaan yang belum siap, lalu klik Ready for review saat selesai.
- Review di Files changed: komentar baris, suggestion, lalu Comment, Approve, atau Request changes.
- Merge commit menjaga semua commit, squash memadatkan jadi satu, rebase membuat riwayat lurus.
- Konflik sederhana bisa diselesaikan di editor web GitHub, yang rumit di laptop: hapus penanda, add, commit, push.
Slide 22 sampai 27 dari deck GitHub. Penjelasan lengkapnya ada di mode Baca.

Selesaikan bab ini
- 1. Baca materi
- 2. Kuis (4 soal)
Cek pemahaman
1Kamu membuka PR untuk menggabungkan `feature/login` ke `main`. Apa yang dipilih sebagai **base**?
2Apa output perintah terakhir berikut?
git switch -c fitur/a # ... dua commit di fitur/a ... git switch main git merge --squash fitur/a git commit -m "Fitur A (#5)" git branch -d fitur/a3Strategi merge mana yang memadatkan semua commit di PR menjadi satu commit di main?
4Draft pull request bisa langsung di-merge selama sudah mendapat satu Approve.
