Konsep Dasarnya Gimana Sih?
Biasanya, kalau kita kerja bareng tim di GitHub, alurnya adalah anak branch (misal: fitur-baru) membuat Pull Request (PR) untuk "meminta izin" agar digabung ke main branch. Tapi, ada cara kerja lain yang lebih "tradisional", di mana anak branch bersifat pasif. Ia hanya fokus mengerjakan tugasnya dan tidak pernah meminta apa-apa. Sebaliknya, main branch lah yang aktif "memanggil" atau "menarik" perubahan dari anak branch saat dibutuhkan. Alur ini memberikan kontrol penuh kepada pengelola branch utama.
Anak Branch yang "Pasif" (Si Pekerja Keras)
Developer di anak branch (misal: fitur-keren) bekerja seperti biasa. Tugasnya hanya dua: mengerjakan kode dan mendorong (push) perubahannya ke branch miliknya sendiri di server. Tidak lebih, tidak kurang. Gak perlu bikin Pull Request sama sekali.
# 1. Pindah ke branch-nya
git checkout fitur-keren
# 2. Mengerjakan kode... lalu commit
git add .
git commit -m "feat: Menambahkan fitur login via google"
# 3. Push hanya ke branch miliknya sendiri. Selesai!
git push origin fitur-kerenMain Branch yang "Aktif" (Sang Manajer)
Sekarang giliran pengelola main branch yang beraksi. Saat dirasa fitur dari fitur-keren sudah siap, sang manajer inilah yang akan menarik perubahan tersebut secara manual dari komputernya.
Langkah 1: Pindah dan Sinkronisasi main
Pastikan kita berada di main dan mengambil versi terbarunya dari server.
git checkout main
git pull origin mainLangkah 2: "Panggil" Perubahan dari Anak Branch
Ini adalah momen kuncinya. Kita gunakan perintah git merge untuk menarik semua commit dari fitur-keren ke main.
git merge fitur-kerenLangkah 3: Publikasikan Hasil Gabungan
Terakhir, dorong (push) main branch yang kini sudah berisi kode baru ke server. Semua perubahan dari fitur-keren kini resmi menjadi bagian dari main.
git push origin mainPerbandingan Alur Kerja
Biar lebih jelas, yuk kita bandingkan metode manual ini dengan metode Pull Request yang lebih umum digunakan.
| Aspek | Metode Manual (Main "Memanggil") | Metode Pull Request (Anak "Meminta") |
|---|---|---|
| Pemicu Merge | Perintah git merge di komputer lokal manajer. | Tombol "Merge" di website GitHub setelah PR disetujui. |
| Diskusi & Review | Tidak tercatat di GitHub. Diskusi terjadi di luar (chat, lisan). | Terpusat & terdokumentasi rapi di halaman Pull Request. |
| Jejak Audit | Hanya terlihat sebagai "merge commit" di riwayat Git. | Ada halaman PR permanen yang mencatat siapa, apa, dan kapan. |
| Tes Otomatis (CI/CD) | Sulit diintegrasikan. Tes tidak berjalan sebelum kode digabung. | Sangat mudah. Tes bisa berjalan otomatis begitu PR dibuat. |
Kapan Pakai Metode Ini?
Metode "memanggil" ini sangat cocok untuk beberapa skenario:
- Proyek Pribadi: Saat kamu kerja sendirian dan gak butuh formalitas.
- Tim Super Kecil: Tim yang isinya 2-3 orang yang sudah sangat tepercaya dan komunikasinya lancar.
- Alur Kerja Otomatis: Saat proses merge dijalankan oleh skrip, bukan oleh manusia.
Namun, untuk kolaborasi tim yang lebih besar, metode Pull Request tetap juaranya karena menyediakan fitur review, diskusi, dan keamanan yang jauh lebih baik.