Apa itu pull request?

Pull request (PR) adalah metode untuk mengusulkan perubahan pada basis kode. Pengembang perangkat lunak melakukan fork pada repositori utama (disebut juga repo) ke cabang terpisah, melakukan commit kode di cabang tersebut selama proses pengembangan, lalu membuat pull request untuk menandai perubahan yang diusulkan agar melalui ulasan kode sebelum perubahan tersebut ditarik atau digabungkan ke basis kode utama.

PR adalah mekanisme umum di repositori Git seperti Bitbucket dan GitHub. GitLab menerapkan istilah “permintaan gabungan” alih-alih permintaan tarik untuk proses yang sama.

Pengembang dapat membuat permintaan tarik menggunakan antarmuka baris perintah (CLI) atau antarmuka web. Pull request baru biasanya dibuka untuk perbaikan bug, pembaruan ketergantungan, fitur baru, atau kode yang direformasi. Pull request menyederhanakan ulasan kode, menjaga basis kode tetap sesuai standar, dan mendorong kolaborasi di antara anggota tim pengembangan perangkat lunak.

PR memungkinkan pengembang untuk membuat kode sumber dan mengujinya secara lokal. Karena perubahan kode diisolasi dari cabang utama, pengembang tidak perlu khawatir tentang merusak seluruh basis kode.

Metodologi pull request melibatkan tiga peran penting yang sebagian besar berlaku untuk proyek sumber terbuka tetapi juga dapat diadopsi oleh proyek berpemilik atau sumber tertutup:

• Pengelola: Pengelola proyek mengelola (dan sering memiliki) proyek dan memiliki wewenang untuk menyetujui dan menggabungkan PR atau menolaknya.

• Peninjau: Anggota tim ini (yang dapat menjadi pengelola sendiri atau kontributor aktif lainnya dengan banyak pengalaman dalam proyek) meninjau perubahan yang diusulkan untuk kualitas kode dan menyarankan perbaikan sesuai keinginan mereka.

• Kontributor: Para pengembang ini ditugaskan untuk membuat perubahan dan membuka pull request.

Membuat pull request umumnya melibatkan prosedur tujuh langkah:

1. Kontributor membagi repositori utama untuk membuat cabang baru (menggunakan git checkout perintah atau antarmuka web) dan mengkloning cabang ini ke mesin lokal mereka.
   
   
2. Kontributor mengerjakan perubahan mereka dan melakukan komitmen kode secara lokal ke cabang.
   
   
3. Setelah kontributor selesai dan menguji kode mereka, mereka pertama-tama menarik pembaruan terbaru dari repo utama untuk menghindari perubahan yang bertentangan sebelum mendorong kode mereka.
   
   
4. Kontributor membuka pull request baru untuk perubahan yang diusulkan untuk diintegrasikan ke dalam cabang utama.
   
   
5. Peninjau menerima pemberitahuan saat pull request dikirimkan. Mereka memeriksa PR untuk membandingkan perbedaan (juga disebut sebagai perbedaan) antara cabang kontributor dan cabang utama, meninjau kode dan memberikan ulasan pada area yang membutuhkan pengoptimalan atau peningkatan.
   
   
6. Kontributor membuat komit tambahan berdasarkan saran pengulas dan permintaan perubahan.
   
   
7. Ketika semua perubahan telah diterapkan, peninjau memberi tahu pengelola, yang menyetujui PR. Permintaan tarik kemudian digabungkan ke repositori utama.

Tim pengembangan perangkat lunak dapat memilih dari sejumlah opsi alur kerja PR bergantung pada kebutuhan mereka. Alur kerja pull request umum meliputi:

• Alur kerja cabang fitur

• Alur kerja forking

• git-flow

• Alur kerja bertumpuk

Setiap fitur baru mendapatkan cabang khusus sendiri dengan nama deskriptif untuk menyoroti tujuan fitur. Setelah fitur selesai, pengembang dapat mendorong cabang fitur ke cabang utama dan membuat pull request.

Alur kerja ini menjaga stabilitas cabang utama karena kontributor bekerja secara terpisah pada fitur. Tetapi mengelola beberapa cabang fitur mungkin menjadi berat.

Prosedur tujuh langkah yang diuraikan di bagian sebelumnya tentang membuat permintaan tarik sesuai dengan alur kerja forking. Proyek open-source sering menggunakan alur kerja ini, yang juga melengkapi praktik integrasi berkelanjutan/pengiriman berkelanjutan (CI/CD). Alur kerja GitHub mengikuti proses yang mirip dengan alur kerja forking.

Insinyur perangkat lunak Vincent Driessen merumuskan git-flow pada tahun 2010. Ini biasanya digunakan untuk membangun perangkat lunak dengan jadwal rilis yang ketat atau yang mendukung berbagai versi.

Alur kerja ini mengikuti model percabangan yang terdiri atas cabang-cabang berikut:

• main memegang rilis stabil terbaru

• develop bertindak sebagai cabang integrasi untuk perbaikan bug, fitur, dan perubahan kode lainnya termasuk dalam rilis berikutnya

• feature menggunakan pengembangan sebagai cabang sumber dan cabang targetnya, dengan fitur digabungkan menjadi pengembangan saat sudah siap

• release di-fork dari pengembangan dan ditandai dengan nomor versi untuk rilis berikutnya, kemudian digabungkan menjadi pengembangan dan main setelah siap untuk dikirimkan

• hotfix dicabang langsung dari utama untuk memperbaiki masalah produksi dengan prioritas tinggi atau tingkat keparahan tinggi, kemudian digabungkan menjadi pengembangan dan main segera setelah perbaikan selesai

Pengembang membuat permintaan pull untuk hotfix , feature dan release cabang yang perlu ulasan.

Alur kerja bertumpuk memecah tugas besar menjadi urutan perubahan kode kecil dan bertahap. Perubahan kode berikutnya bergantung pada perubahan kode sebelumnya, jadi pull request dibangun di atas satu sama lain.

Pertimbangkan fitur yang melibatkan perubahan pada fungsi-fungsi ini: basis data atau model data, API, dan front end. Dalam cabang fitur konvensional atau alur kerja forking, kontributor harus menunggu PR untuk perubahan database atau model data untuk ditinjau, disetujui, dan digabungkan ke cabang utama sebelum mereka dapat memulai pembaruan API. Dalam alur kerja bertumpuk, periode tunggu ini dihapuskan—kontributor dapat bercabang dari perubahan database atau model data untuk mulai mengerjakan API, Kirim PR untuk itu, dan mencabangkan perubahan API untuk menangani tugas front-end.

Pull request menawarkan keuntungan berikut:

• Menumbuhkan kolaborasi

• Meningkatkan kualitas kode

• Meningkatkan transparansi

• Memperkuat keterampilan pengodean

Pull request mendorong kerja sama, mendorong anggota tim untuk bekerja sama terlepas dari peran mereka. PR memfasilitasi masukan dan cara menghadapinya, memicu diskusi dan memicu ide untuk penyempurnaan.

PR memulai proses ulasan kode, membantu menentukan bug, penyimpangan dari gaya dan standar pengodean, masalah kinerja, dan kerentanan keamanan keamanan kerentanan. Pengawasan tambahan ini mempertahankan atau bahkan meningkatkan kualitas kode.

Pull request memungkinkan tim untuk melihat perubahan apa yang diterapkan, siapa yang membuatnya, di mana perubahan itu diterapkan dan alasan di baliknya. Visibilitas tersebut memberikan insight yang lebih baik tentang keadaan basis kode dan proyek itu sendiri.

Baik pengulas maupun kontributor dapat belajar dari satu sama lain, mengambil teknik baru di sepanjang jalan dan menemukan pendekatan baru untuk masalah. Pemula dan anggota tim baru juga dapat mempelajari PR sebelumnya untuk lebih memahami basis kode dan mempercepat standar pengodean tim dan praktik terbaik.

Meskipun membuat pull request terlihat mudah, berikut ini adalah beberapa tips dan trik yang dapat memperlancar prosesnya:

• Pertimbangkan konsep

• Detail penting

• Pertahankan fokus

• Tetap terkini

• Gunakan templat

Draft pull request atau merge request berfungsi sebagai sarana bagi developer untuk membagikan pekerjaan yang masih dalam proses. Hal ini memungkinkan anggota tim untuk memulai kolaborasi lebih awal dan mengundang masukan lebih cepat sehingga mereka yang terjebak pada masalah dapat mengumpulkan solusi potensial dari rekan tim mereka.

Pengembang harus memberikan pesan yang jelas, ringkas, dan spesifik untuk setiap commit baru mereka. Kejelasan, keringkasan, dan kekhususan juga berlaku untuk judul dan deskripsi PR, membuatnya lebih mudah dan lebih cepat bagi pengulas untuk mengumpulkan maksud di balik perubahan kode.

Menggabungkan beberapa masalah ke dalam satu PR dapat menghasilkan waktu peninjauan yang lebih lama dan lebih banyak revisi. Setiap pull request hanya boleh alamat satu perbaikan bug atau fitur. Pull request yang terfokus dapat menghasilkan ulasan kode yang lebih efisien.

Sebelum mendorong kode dan membuka PR, pengembang harus memastikan cabang mereka mutakhir. Mengambil perubahan terbaru dan setiap komit baru mencegah konflik setelah pull request digabungkan. Mereka dapat menggunakan salah satu git pull perintah untuk mengambil dan menggabungkan perubahan dari cabang target atau git rebase perintah untuk riwayat komit git yang bersih.

Templat deskripsi PR membantu memastikan konsistensi dan memberikan konteks penting untuk merampingkan ulasan kode. Tim dapat membuat templat untuk berbagai jenis permintaan tarik, seperti perbaikan bug, fitur, atau kode yang difaktorkan ulang.

Templat biasanya ditulis menggunakan bahasa markup Markdown dan ditempatkan di folder root atau cabang utama repo proyek. Bidang umum meliputi:

• Deskripsi masalah atau fitur (dengan tautan ke tiket yang sesuai di Jira atau perangkat lunak pelacakan masalah lainnya untuk referensi)

• Solusi menguraikan perubahan kode secara detail

• Pengujian, seperti kasus pengujian unit atau uji integrasi, cakupan pengujian, dan langkah-langkah untuk memvalidasi solusi secara manual jika berlaku

• Perubahan konfigurasi

• Daftar periksa tugas yang relevan, seperti dokumentasi kode dan pembuatan kode bersih tanpa kesalahan atau peringatan

Mengotomatiskan PR dapat mempercepat siklus proses permintaan tarik dari pembuatan hingga ulasan dan penggabungan. Otomatisasi PR mencakup lapisan sistem yang membantu meringankan kemacetan:

• PR bertumpuk

• Pipeline CI/CD

• Sistem manajemen SDLC

• Asisten pengodean didukung AI

Sebagian besar repositori Git tidak dirancang untuk mendukung alur kerja bertumpuk, tetapi beberapa alat menghilangkan kompleksitas sinkronisasi permintaan tarik bertumpuk dan menangani konflik penggabungan. Alat-alat ini termasuk platform Graphite , yang memiliki CLI dan ekstensi untuk VS Code Microsoft untuk PR bertumpuk dan antarmuka web untuk mengelolanya; sistem manajemen kode sumber Sapling Meta; dan CLI ghstack sumber terbuka untuk mengirimkan diff bertumpuk ke GitHub sebagai permintaan tarik terpisah.

Sebagai alur kerja DevOps otomatis, pipeline CI/CD membantu memastikan kualitas kode. Platform seperti GitHub Actions dan GitLab dan alat CI lainnya dapat menjalankan pengujian unit dan pengujian integrasi dan menerapkan lingkungan pratinjau yang bertindak sebagai sandbox untuk melihat dan menguji perubahan kode dalam PR.

Pipeline CI/CD juga memperkuat praktik pengodean yang aman. Penganalisis kode statis dan alat pengujian keamanan aplikasi statis (SAST) lainnya terintegrasi dengan lancar dengan sebagian besar lingkungan CI/CD untuk menentukan kemungkinan kerentanan kode. Tim DevOps dapat menerapkan kait pra-komit untuk deteksi rahasia, menjadikan pemindaian rahasia sebagai langkah yang diperlukan sebelum pengembang melakukan kode atau memulai permintaan tarik dan memblokir perubahan yang berisi rahasia hardcode.

Platform seperti Jira dan IBM® Engineering Lifecycle Management (ELM) mendukung pelacakan dan pengelolaan permintaan tarik sepanjang siklus pengembangan perangkat lunak (SDLC).

Sebagai bagian dari rangkaian ELM, IBM Engineering Workflow Management (EWM) dan IBM® Engineering Integration Hub menanamkan otomatisasi PR langsung ke alur kerja pengembangan. EWM dapat terhubung dengan repositori Git melalui konektor Hub dan memicu pembuatan PR dari item kerja. Ketika persyaratan atau permintaan perubahan disetujui di EWM, aturan dapat secara otomatis membuka permintaan tarik di repositori Git yang ditautkan dan mengisi deskripsi terlebih dahulu.

Otomatisasi yang digerakkan Aldi ELM juga dapat menjalankan analisis statis dan rangkaian pengujian setelah PR dibuka, memposting hasil kembali ke item kerja dan memblokir penggabungan sampai kriteria terpenuhi. Sementara itu, Hub menyinkronkan status PR di seluruh alat, merefleksikannya di repositori dan dasbor EWM untuk visibilitas real-time.

Asisten pengodean didukung AI seperti GitHub Copilot dan IBM® Bob dapat menambah alur kerja pull request. Misalnya, Bob dapat menghasilkan pesan commit yang diformat dengan baik dan bermakna. Fitur ini memeriksa nama cabang dan riwayat commit untuk mencocokkan konvensi gaya proyek.

Bob juga dapat membuat pull request secara langsung dari IDE pengembang. Analisis ini mencakup nama cabang, perubahan kode, dan riwayat commit untuk memahami tujuan dan ruang lingkupnya. Kemudian menghasilkan judul PR dan deskripsi terperinci yang merangkum perubahan, secara otomatis mendeteksi dan menggunakan templat PR proyek yang ada untuk deskripsi full request.