Tentang permintaan tarik

Layanan Azure DevOps | Azure DevOps Server | Azure DevOps Server 2022

Permintaan pull (PR) adalah cara untuk mengubah, meninjau, dan menggabungkan kode di repositori Git di Azure Repos. PR dapat berasal dari cabang dalam repositori yang sama atau dari cabang di fork repositori. Teams menggunakan PR untuk meninjau kode dan memberikan umpan balik tentang perubahan sebelum menggabungkan kode ke cabang utama. Peninjau dapat menelusuri perubahan yang diusulkan, meninggalkan komentar, dan memilih untuk menyetujui atau menolak kode.

Untuk panduan komprehensif tentang melindungi repositori selama permintaan pull melalui kebijakan cabang, kontrol akses, dan verifikasi penerapan, lihat Mengamankan repositori dan permintaan pull.

Artikel ini menjelaskan panduan permintaan pull dan pertimbangan manajemen. Untuk petunjuk tentang cara membuat, melihat, meninjau, dan menyelesaikan permintaan pull, lihat artikel berikut ini:

Catatan

Untuk alasan performa dan stabilitas, jumlah peninjau yang dapat ditambahkan ke permintaan pull harus 1000 atau kurang. Permintaan pull baru tidak akan dibuat saat menambahkan lebih dari 1000 peninjau, dan permintaan pull yang ada tidak akan memungkinkan Anda untuk menambahkan lebih dari 1000 peninjau.

Petunjuk / Saran

Anda dapat menggunakan AI untuk membantu tugas Azure DevOps. Lihat Mengaktifkan bantuan AI dengan Azure DevOps MCP Server untuk memulai.

Izin dan prasyarat

  • Repositoriitori harus diaktifkan pada proyek Anda. Jika hub Repositori dan halaman terkait tidak ditampilkan, lihat Mengaktifkan atau menonaktifkan layanan Azure DevOps untuk mengaktifkan kembali Repositoriitori.

  • Untuk melihat atau meninjau PR, jadilah anggota proyek Azure DevOps dengan setidaknya akses Dasar.

  • Untuk berkontribusi dalam PR, menjadi anggota grup keamanan Pembaca atau memiliki izin yang sesuai.

  • Untuk membuat dan menyelesaikan PR, jadilah anggota grup keamanan kontributor atau pastikan Anda memiliki izin yang sesuai.

Catatan

Untuk proyek publik, pengguna yang diberikan akses Pemangku Kepentingan memiliki akses penuh ke Azure Repos.

  • Repositoriitori harus diaktifkan pada proyek Anda. Jika hub Repositori dan halaman terkait tidak ditampilkan, lihat Mengaktifkan atau menonaktifkan layanan Azure DevOps untuk mengaktifkan kembali Repositoriitori.
  • Untuk melihat atau meninjau PR, jadilah anggota proyek Azure DevOps dengan setidaknya akses Dasar. Jika Anda bukan anggota proyek, tambahkan.
  • Untuk berkontribusi dalam PR, menjadi anggota grup keamanan Pembaca atau memiliki izin yang sesuai.
  • Untuk membuat dan menyelesaikan PR, jadilah anggota grup keamanan kontributor atau pastikan Anda memiliki izin yang sesuai.

Untuk informasi selengkapnya tentang izin dan akses, lihat Repositori Git default dan izin cabang dan Tentang tingkat akses.

Kualitas umpan balik untuk permintaan tarik

Ulasan berkualitas tinggi dimulai dengan umpan balik berkualitas tinggi. Berikut adalah beberapa kunci untuk umpan balik PR yang bagus:

  • Pemilik PR harus memastikan orang yang tepat meninjau PR, dan memastikan agar peninjau mengetahui apa yang dilakukan kode tersebut.
  • Peninjau harus memberikan umpan balik yang dapat ditindakkan dan konstruktif.
  • Pemilik dan peninjau sebaiknya berkomentar dan membalas dengan cepat.

Pemilik PR harus:

  • Pastikan untuk memilih peninjau yang tepat untuk ditugaskan ke PR.
  • Sertakan peninjau yang mengetahui cara kerja kode.
  • Minta pengembang yang bekerja di area lain untuk berbagi ide mereka.
  • Berikan deskripsi yang jelas tentang perubahan.
  • Berikan panduan peninjau dengan templat permintaan pull.
  • Berikan build kode dengan perbaikan atau fitur yang berjalan di dalamnya.
  • Balas komentar, terima saran atau jelaskan mengapa perubahan yang disarankan tidak ideal.
  • Untuk saran yang baik di luar lingkup PR, buat item kerja, cabang, dan PR baru untuk membuat perubahan tersebut.

Peninjau harus melakukan tugas berikut.

  • Memberikan umpan balik tentang perubahan yang tidak mereka setujui
  • Mengidentifikasi masalah dan memberikan saran khusus tentang apa yang harus dilakukan secara berbeda
  • Pastikan umpan balik memiliki niat yang jelas dan mudah dipahami
  • Tinggalkan komentar atau pilih pada perubahan

Untuk informasi selengkapnya, lihat Dapatkan umpan balik dengan pull request Git.

Kebijakan cabang dan permintaan pull

Tim Anda mungkin mengandalkan cabang penting di repositori Anda, seperti cabang main, agar selalu dalam kondisi baik. Anda dapat mengatur kebijakan cabang untuk mewajibkan PR untuk setiap perubahan pada cabang yang dilindungi ini, dan menolak perubahan apa pun yang didorong langsung ke cabang.

Anda dapat menambahkan lebih banyak kebijakan ke PR untuk menerapkan peningkatan kualitas kode di cabang-cabang utama. Persyaratan tambahan seperti kompilasi bersih dari kode yang diajukan atau persetujuan dari beberapa peninjau dapat membantu melindungi branch utama.

Anda dapat mengatur jumlah persetujuan yang diperlukan untuk PR dalam kebijakan cabang. Anda juga dapat mengatur peninjau tertentu agar wajib atau opsional pada semua atau beberapa Permintaan Penarikan. PR dapat diatur untuk mencapai penyelesaian otomatis dengan jumlah persetujuan yang dibutuhkan, terlepas dari penolakan dari peninjau lain terhadap perubahan. Namun, peninjau yang diperlukan harus menyetujui PR sebelum PR dapat digabungkan. Ini adalah praktik terbaik bagi setidaknya dua peninjau untuk meninjau dan menyetujui perubahan dalam PR yang signifikan.

Untuk mengatur ulang suara setiap kali pengarang PR mengirimkan perubahan baru, pilih Atur ulang suara peninjau kode ketika ada perubahan baru di dalam kebijakan cabang 'Memerlukan jumlah minimum peninjau'.

Tabel berikut ini meringkas kebijakan yang bisa Anda tentukan untuk mengkustomisasi cabang. Untuk gambaran umum semua kebijakan dan pengaturan repositori dan cabang, lihat Pengaturan dan kebijakan repositori Git.

Kebijakan

Default

Keterangan

Memerlukan jumlah minimum peninjau

Nonaktif

Memerlukan persetujuan dari jumlah peninjau yang ditentukan untuk permintaan pull.

Periksa item kerja tertaut

Nonaktif

Dorong keterlacakan dengan memeriksa item kerja tertaut pada permintaan pull

Periksa penyelesaian komentar

Nonaktif

Pastikan bahwa semua komentar telah diselesaikan pada pull request.

Batasi jenis penggabungan

Nonaktif

Kontrol riwayat cabang dengan membatasi jenis penggabungan yang tersedia saat permintaan pull selesai.

Menambahkan kebijakan validasi build

Nonaktif

Tambahkan satu atau beberapa kebijakan untuk memvalidasi kode dengan melakukan pra-penggabungan dan membangun perubahan permintaan pull. Juga dapat mengaktifkan atau menonaktifkan kebijakan.

Menambahkan kebijakan Pemeriksaan Status

Nonaktif

Tambahkan satu atau beberapa kebijakan untuk mengharuskan layanan lain memposting status berhasil untuk menyelesaikan permintaan pull. Juga dapat mengaktifkan atau menonaktifkan kebijakan.

Peninjau yang disertakan secara otomatis

Nonaktif

Tambahkan satu atau beberapa kebijakan untuk menunjuk peninjau kode untuk disertakan secara otomatis saat permintaan pull mengubah area kode tertentu. Juga dapat mengaktifkan atau menonaktifkan kebijakan.

Untuk informasi selengkapnya, lihat:

Menentukan pemeriksaan status untuk meningkatkan kualitas kode

Permintaan pull dan kebijakan cabang memungkinkan tim menerapkan praktik terbaik untuk meninjau kode dan menjalankan build otomatis. Banyak tim memiliki persyaratan dan validasi lebih lanjut untuk dilakukan pada kode. Untuk memenuhi kebutuhan ini, Anda dapat mengintegrasikan pemeriksaan status PR ke dalam alur kerja PR. Dengan pemeriksaan status PR, layanan eksternal dapat secara terprogram menandatangani perubahan kode dengan mengaitkan informasi keberhasilan atau kegagalan dengan PR.

Untuk informasi lebih lanjut, baca artikel berikut:

Beberapa masalah dasar dalam penggabungan

Dalam beberapa kasus, PR memiliki lebih dari satu basis penggabungan sejati, dan situasi ini dapat menyebabkan masalah keamanan. Jika file dalam permintaan pull memiliki versi yang berbeda antar basis penggabungan, beberapa peringatan basis penggabungan akan terjadi. Untuk informasi selengkapnya dan remediasi, lihat Berbagai basis penggabungan.

Langkah berikutnya

  • Terakhir diperbarui pada