Mengatur dan mengelola kebijakan cabang

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

Gunakan kebijakan cabang untuk melindungi cabang penting dengan mewajibkan pull request, peninjau, build, dan pemeriksaan lainnya sebelum perubahan digabungkan. Artikel ini memperlihatkan cara mengonfigurasi dan mengelola kebijakan cabang di portal web Azure DevOps dan Azure DevOps CLI. Untuk ringkasan kebijakan cabang dan panduan percabangan yang tersedia, lihat Tentang kebijakan cabang dan cabang.

Untuk panduan keamanan yang lengkap yang mencakup kebijakan cabang, kontrol akses repositori, penandatanganan commit, dan skenario penerapan di dunia nyata, lihat Mengamankan repositori dan pull request.

Anda tidak dapat menghapus cabang yang dikonfigurasi dengan kebijakan wajib, dan semua perubahan harus melalui pull request (PR).

Petunjuk / Saran

Anda dapat menggunakan AI untuk membantu tugas ini nanti dalam artikel ini, atau lihat Aktifkan bantuan AI dengan Azure DevOps MCP Server untuk memulai.

Prasyarat

Requirement Rincian
Permissions Harus menjadi anggota grup keamanan Administrator Proyek, atau memiliki izin Edit kebijakan pada tingkat repositori. Untuk informasi selengkapnya, lihat Mengatur izin repositori Git.
penyiapan CLI Azure DevOps (opsional) Untuk menggunakan perintah az repos policy Azure DevOps CLI, ikuti Mulai menggunakan Azure DevOps CLI.
Penentuan repositori target untuk CLI (opsional) Sebelum Anda membuat atau memperbarui kebijakan di CLI, identifikasi ID repositori dengan menjalankan az repos list. Untuk menghindari pengulangan --org dan --project, atur default dengan az devops configure --defaults.
Dependensi kebijakan Sebelum Anda mengonfigurasi validasi Build, siapkan alur build. Sebelum Anda mengonfigurasi pemeriksaan status, pastikan layanan eksternal atau integrasi bawaan sudah dapat mengirimkan status pull request.
Penyiapan bantuan AI (opsional) Untuk menggunakan bantuan AI dengan Azure DevOps MCP Server, gunakan Azure DevOps Services, aktifkan mode agen di asisten AI Anda, dan instal Node.js 20.0+. Untuk informasi selengkapnya, lihat Mengaktifkan bantuan AI dengan Azure DevOps McP Server.
Requirement Rincian
Permissions Harus menjadi anggota grup keamanan Administrator Proyek, atau memiliki izin Mengedit kebijakan pada tingkat repositori. Untuk informasi selengkapnya, lihat Mengatur izin repositori Git.

Buka pengaturan kebijakan cabang

Untuk membuka pengaturan kebijakan cabang di portal web:

  1. Pilih Repositori>Cabang.
  2. Temukan cabang yang ingin Anda kelola.
  3. Pilih ikon Opsi lainnya di samping cabang, lalu pilih Kebijakan cabang.

Cuplikan layar yang menampilkan item menu Cabang.

Anda juga dapat membuka pengaturan kebijakan cabang dari Pengaturan proyek>Repositori>Kebijakan>Kebijakan cabang><Nama cabang>.

Cabang yang memiliki kebijakan menampilkan ikon kebijakan. Pilih ikon untuk langsung masuk ke pengaturan kebijakan cabang.

Anda dapat menelusuri daftar atau mencari cabang di kotak Nama cabang pencarian .

Cuplikan layar yang memperlihatkan Buka kebijakan cabang dari menu konteks.

Konfigurasikan kebijakan pada halaman pengaturan cabang. Gunakan bagian berikut untuk mengaktifkan atau memperbarui kebijakan yang sudah ada.

Tetapkan kebijakan jumlah minimum peninjau

Memerlukan persetujuan dari jumlah minimum peninjau sebelum permintaan pull dapat diselesaikan.

Untuk mengatur kebijakan, di bawah Kebijakan Cabang, atur Memerlukan jumlah minimum peninjau ke Aktif. Masukkan jumlah peninjau yang diperlukan, dan pilih salah satu opsi berikut:

Cuplikan layar yang memperlihatkan kebijakan Memerlukan Tinjauan Kode diaktifkan.

  • Pilih Izinkan pemohon menyetujui perubahan mereka sendiri untuk memungkinkan pembuat PR memberikan suara untuk persetujuannya. Jika tidak, pembuat masih dapat memberikan suara Setujui pada PR, tetapi suaranya tidak dihitung sebagai bagian dari jumlah minimum peninjau yang diperlukan.

  • Pilih Larang pendorong terbaru untuk menyetujui perubahannya sendiri guna menerapkan pemisahan tugas. Secara default, siapa pun dengan izin push pada cabang sumber dapat menambahkan komit dan memberikan persetujuan pada PR. Memilih opsi ini berarti suara pengusul terbaru tidak dihitung, bahkan jika mereka biasanya dapat menyetujui perubahan mereka sendiri.

  • Pilih Izinkan penyelesaian meskipun beberapa peninjau memilih untuk menunggu atau menolak untuk mengizinkan penyelesaian PR meskipun beberapa peninjau memilih menolak persetujuan. Jumlah minimum peninjau masih harus memberikan persetujuan.

  • Di bawah Saat perubahan baru didorong:
    • Pilih Perlu setidaknya satu persetujuan pada setiap perulangan untuk memerlukan setidaknya satu suara persetujuan untuk perubahan cabang sumber terakhir. Persetujuan pengguna tidak dihitung terhadap perulangan yang tidak disetujui sebelumnya yang didorong oleh pengguna tersebut. Akibatnya, persetujuan lain pada iterasi terakhir diperlukan untuk dilakukan oleh pengguna lain. Memerlukan setidaknya satu persetujuan pada setiap iterasi tersedia di Azure DevOps Server 2022.1 dan yang lebih tinggi.
    • Pilih Perlu setidaknya satu persetujuan pada iterasi terakhir untuk memerlukan setidaknya satu suara persetujuan untuk perubahan cabang sumber terakhir.
    • Pilih Reset semua suara persetujuan (tidak mengatur ulang suara untuk menolak atau menunggu) untuk menghapus semua suara persetujuan, tetapi pertahankan suara untuk menolak atau menunggu, setiap kali cabang sumber berubah.
    • Pilih Reset semua suara peninjau kode untuk menghapus semua suara peninjau kode setiap kali cabang sumber berubah, termasuk suara untuk menyetujui, menolak, atau menunggu.

Jika semua kebijakan lainnya disetujui, pencipta dapat menyelesaikan PR ketika jumlah peninjau yang diperlukan telah menyetujuinya.

Wajibkan item kerja yang ditautkan

Untuk pelacakan manajemen item kerja, Anda dapat memerlukan asosiasi antara PR dan item kerja. Menautkan item kerja menyediakan lebih banyak konteks untuk perubahan, dan memastikan bahwa pembaruan melewati proses pelacakan item kerja Anda.

Untuk mengatur kebijakan, di bawah Kebijakan Cabang, atur Periksa item kerja yang tertaut ke Aktif. Pengaturan ini mengharuskan item kerja ditautkan ke PR sebelum PR dapat digabungkan. Buat pengaturan Opsional untuk memperingatkan ketika tidak ada item kerja tertaut, tetapi izinkan penyelesaian permintaan pull.

Cuplikan layar yang memerlukan item kerja tertaut dalam permintaan pull.

Perlu penyelesaian komentar

Kebijakan Memeriksa penyelesaian komentar memastikan bahwa semua komentar PR telah diselesaikan.

Atur Periksa resolusi komentar ke Aktif untuk mengonfigurasi kebijakan resolusi komentar untuk cabang Anda. Kemudian pilih apakah akan membuat kebijakan Diperlukan atau Opsional.

Cuplikan layar Periksa resolusi komentar.

Untuk informasi selengkapnya tentang menggunakan komentar pull request, lihat Meninjau pull request.

Batasi jenis penggabungan

Azure Repos mendukung beberapa strategi penggabungan, dan secara default, itu memungkinkan semuanya. Untuk mempertahankan riwayat cabang yang konsisten, terapkan strategi penggabungan untuk penyelesaian PR.

Atur Batasi jenis penggabungan ke Aktif untuk membatasi jenis penggabungan mana yang diizinkan dalam repositori Anda.

Cuplikan layar Batasi jenis penggabungan.

  • Penggabungan dasar (tanpa fast-forward) membuat commit penggabungan di target yang memiliki induk berupa cabang target dan cabang sumber.
  • Squash merge menciptakan riwayat linear dengan satu komit di cabang target yang mencakup perubahan dari cabang sumber. Pelajari selengkapnya tentang penggabungan squash dan pengaruhnya terhadap riwayat cabang.
  • Rebase dan fast-forward membuat riwayat linier dengan memutar ulang commit dari sumber ke cabang target tanpa commit penggabungan.
  • Rebase dengan commit penggabungan memutar ulang commit sumber ke target dan juga membuat commit penggabungan.

Mengatur validasi build

Tetapkan kebijakan yang memerlukan perubahan PR agar berhasil dibangun sebelum PR dapat diselesaikan. Kebijakan pembangunan mengurangi gangguan dan menjaga hasil pengujian Anda tetap berhasil. Kebijakan build membantu meskipun Anda menggunakan Continuous Integration (CI) di cabang pengembangan Anda untuk mengidentifikasi masalah sebelumnya.

Saat Anda mengatur pemicu kebijakan ke Otomatis, kebijakan validasi build akan mengantrikan build baru saat Anda membuat PR baru atau mendorong perubahan ke PR yang sudah ada yang menargetkan cabang tersebut. Jika Anda mengatur pemicu kebijakan ke Manual, pengguna harus mengantre build itu sendiri. Dalam kedua kasus, kebijakan mengevaluasi hasil kompilasi untuk menentukan apakah PR dapat diselesaikan.

Penting

Sebelum menentukan kebijakan validasi build, buat alur build. Jika Anda tidak memiliki alur, lihat Membuat alur build. Pilih jenis build yang cocok dengan jenis proyek Anda.

Untuk menambahkan kebijakan validasi penyusunan

  1. Pilih tombol + di sebelah Validasi build.

    Cuplikan layar yang memperlihatkan tombol Tambahkan di samping Validasi build.

  2. Isi formulir Tetapkan kebijakan build:

    Cuplikan layar pengaturan kebijakan build.

    • Pilih Build pipeline.

  • Atur filter jalur secara opsional. Pelajari selengkapnya tentang filter jalur dalam kebijakan cabang.

  • Di bawah Pemicu, pilih Otomatis (setiap kali cabang sumber diperbarui) atau Manual.

  • Di bawah Persyaratan kebijakan, pilih Diperlukan atau Opsional. Jika Anda memilih Diperlukan, build harus berhasil diselesaikan untuk menyelesaikan PR. Pilih Opsional untuk memberikan pemberitahuan kegagalan build tetapi tetap memungkinkan penyelesaian PR.

  • Atur kedaluwarsa pembentukan untuk memastikan pembaruan ke cabang Anda yang dilindungi tidak mengganggu perubahan pada PR yang terbuka.

    • Segera ketika <nama> cabang diperbarui: Opsi ini mengatur status kebijakan build PR menjadi gagal setiap kali cabang diperbarui, dan mengulang antrean build. Pengaturan ini memastikan bahwa perubahan PR berhasil dikompilasi meskipun cabang yang dilindungi mengalami perubahan.

      Opsi ini terbaik untuk tim yang cabang pentingnya memiliki sedikit perubahan. Tim yang bekerja di cabang pengembangan yang sibuk mungkin merasa terganggu harus menunggu build setiap kali cabang tersebut diperbarui.

    • Setelah <n> jam jika <nama> cabang telah diperbarui: Opsi ini akan mengakhiri status kebijakan saat ini ketika cabang yang dilindungi diperbarui, jika build yang berhasil lebih lama dari ambang batas yang Anda masukkan. Opsi ini merupakan kompromi antara selalu memerlukan build atau tidak pernah memerlukannya ketika cabang dilindungi diperbarui. Pilihan ini mengurangi jumlah build saat cabang anda yang dilindungi memiliki pembaruan yang sering.

    • Tidak Pernah: Pembaruan pada cabang yang dilindungi tidak mengubah status kebijakan. Nilai ini mengurangi jumlah build, tetapi dapat menyebabkan masalah saat menyelesaikan PR yang tidak diperbarui baru-baru ini.

  • Masukkan Nama tampilan opsional untuk kebijakan build ini. Nama ini mengidentifikasi kebijakan pada halaman Kebijakan cabang. Jika Anda tidak menentukan nama tampilan, kebijakan menggunakan nama alur build.

  1. Pilih Simpan.

Ketika pemilik PR mendorong perubahan yang berhasil dibangun, status kebijakan diperbarui.

Jika Anda memiliki kebijakan build Segera setelah <nama cabang> diperbarui atau Setelah <n> jam jika <nama cabang> diperbarui, status kebijakan akan diperbarui saat cabang yang dilindungi diperbarui, jika build sebelumnya tidak lagi valid.

Memerlukan pemeriksaan status

Layanan eksternal dapat menggunakan PR Status API untuk memposting status terperinci ke PR Anda. Kebijakan cabang untuk layanan tambahan memungkinkan layanan eksternal tersebut untuk berpartisipasi dalam alur kerja PR dan menetapkan persyaratan kebijakan.

Cuplikan layar Memerlukan layanan eksternal untuk disetujui.

Untuk mengonfigurasi kebijakan pemeriksaan status:

  1. Pastikan layanan dapat memublikasikan status permintaan pull ke Azure Repos.
  2. Di Kebijakan cabang, di bawah Pemeriksaan status, pilih +.
  3. Di Status untuk memeriksa, pilih pemeriksaan yang diposting dari daftar. Jika layanan belum memublikasikan status, ketik nilai genre/name secara langsung.
  4. Atur Persyaratan kebijakan ke Diperlukan atau Opsional.
  5. Secara opsional mengonfigurasi identitas resmi, Mengatur ulang kondisi, Penerapan kebijakan, dan Filter jalur.
    • Gunakan Terapkan secara default jika kebijakan harus berlaku segera setelah permintaan pull dibuat.
    • Gunakan Conditional jika kebijakan hanya boleh berlaku setelah status pertama dipublikasikan.
  6. Buat atau perbarui permintaan pull yang menargetkan cabang, dan konfirmasikan bahwa kebijakan muncul di bagian Kebijakan PR.

Untuk pemeriksaan Layanan Azure DevOps bawaan dan pengidentifikasinyagenre/name, lihat Pemeriksaan status permintaan pull yang tersedia. Untuk panduan lengkap penyiapan layanan eksternal, lihat Mengonfigurasi kebijakan cabang untuk layanan eksternal.

Jika integrasi baru belum muncul di menu tarik-turun, kirim status sekali dari layanan tersebut, lalu tambahkan kebijakan, atau ketik langsung nilai genre/name.

Secara otomatis menyertakan peninjau

Anda dapat secara otomatis menambahkan peninjau ke pull request yang mengubah file di direktori atau file tertentu, atau ke semua pull request dalam repo.

  1. Pilih tombol + di samping Peninjau yang Secara Otomatis Disertakan.

    Cuplikan layar yang memperlihatkan Tambahkan peninjau yang diperlukan.

  2. Isi layar Tambahkan kebijakan peninjau baru.

    Cuplikan layar yang memperlihatkan layar Tambahkan kebijakan peninjau baru.

    • Tambahkan orang dan grup ke Peninjau.

    • Pilih Opsional jika Anda ingin menambahkan peninjau secara otomatis, tetapi tidak memerlukan persetujuan mereka untuk menyelesaikan permintaan pull.

      Atau, pilih Diperlukan jika permintaan pull tidak dapat diselesaikan hingga:

      • Setiap individu ditambahkan sebagai peninjau menyetujui perubahan.
      • Setidaknya satu orang di setiap grup yang ditambahkan sebagai peninjau menyetujui perubahan.
      • Jika hanya satu grup yang diperlukan, jumlah minimum anggota yang Anda tentukan menyetujui perubahan.

    • Tentukan file dan folder yang memerlukan peninjau yang disertakan secara otomatis. Biarkan bidang ini kosong untuk mengharuskan peninjau untuk semua permintaan pull di cabang.

    • Pilih Izinkan pemohon untuk menyetujui perubahan mereka sendiri jika pemilik permintaan pull dapat memilih untuk menyetujui permintaan pull mereka sendiri untuk memenuhi kebijakan ini.

    • Anda dapat menentukan pesan Umpan aktivitas yang muncul di permintaan penarikan.

  3. Pilih Simpan.

Izinkan melewati kebijakan jika diperlukan

Dalam beberapa kasus, Anda mungkin perlu melewati persyaratan kebijakan. Izin bypass memungkinkan Anda mendorong perubahan ke cabang secara langsung, atau menyelesaikan permintaan pull yang tidak memenuhi kebijakan cabang. Anda dapat memberikan izin bypass kepada pengguna atau grup, dan mencakup izin tersebut ke seluruh proyek, repositori, atau satu cabang.

Dua izin memungkinkan pengguna untuk melewati kebijakan cabang dengan cara yang berbeda:

  • Melewati kebijakan saat menyelesaikan permintaan pull hanya berlaku untuk penyelesaian permintaan pull. Pengguna dengan izin ini dapat menyelesaikan permintaan pull meskipun permintaan pull tidak memenuhi kebijakan.

  • Melewati kebijakan ketika push berlaku untuk push pada repositori lokal dan pengeditan di web. Pengguna dengan izin ini dapat mendorong perubahan langsung ke cabang yang dilindungi tanpa memenuhi persyaratan kebijakan.

Cuplikan layar yang menunjukkan izin untuk melewati penegakan kebijakan.

Untuk informasi selengkapnya tentang mengelola izin ini, lihat Izin Git.

Penting

Berhati-hatilah saat memberikan kemampuan untuk melewati kebijakan, terutama di tingkat repositori dan proyek. Kebijakan adalah landasan manajemen kode sumber yang aman dan sesuai.

Gunakan filter jalur dengan kebijakan cabang

Beberapa kebijakan cabang mendukung filter jalur. Jika Anda mengatur filter jalur, kebijakan hanya berlaku untuk file yang cocok dengan filter. Biarkan bidang ini kosong untuk menerapkan kebijakan ke semua file di cabang.

Anda dapat menentukan jalur absolut (jalur harus diawali dengan / atau karakter pengganti) dan karakter pengganti. Contoh:

  • /WebApp/Models/Data.cs
  • /WebApp/*
  • */Models/Data.cs
  • *.cs

Anda dapat menentukan beberapa jalur dengan menggunakan ; sebagai pemisah. Contoh:

  • /WebApp/Models/Data.cs;/ClientApp/Models/Data.cs

Jika Anda menambahkan awalan ! pada jalur, jalur tersebut akan dikecualikan jika sebelumnya seharusnya disertakan. Contoh:

  • /WebApp/*;!/WebApp/Tests/* menyertakan semua file dalam /WebApp kecuali file di /WebApp/Tests
  • !/WebApp/Tests/* menentukan tidak ada file, karena tidak ada yang disertakan terlebih dahulu

Urutan filter signifikan. Terapkan filter kiri-ke-kanan.

Memecahkan Masalah Kebijakan Cabang

Dapatkah saya mendorong perubahan langsung ke cabang yang memiliki kebijakan cabang?

Anda tidak dapat menerapkan perubahan secara langsung pada cabang dengan kebijakan cabang yang wajib kecuali Anda memiliki izin untuk melewati kebijakan cabang. Anda hanya dapat membuat perubahan pada cabang ini melalui permintaan pull. Anda dapat mendorong perubahan langsung ke cabang yang memiliki kebijakan cabang opsional , jika mereka tidak memiliki kebijakan cabang yang diperlukan.

Apa itu pelengkapan otomatis?

Cabang dengan kebijakan cabang yang dikonfigurasi untuk permintaan pull memiliki tombol Atur lengkapi otomatis . Pilih opsi ini untuk mengatur permintaan pull untuk melengkapi otomatis setelah memenuhi semua kebijakan. Pelengkapan otomatis berguna saat Anda tidak menduga akan ada masalah dengan perubahan.

Kapan dilakukan pemeriksaan terhadap kondisi kebijakan cabang?

Server mengevaluasi ulang kebijakan cabang saat pemilik pull request mendorong perubahan dan saat peninjau memberikan suara. Jika kebijakan memicu build, status build diatur untuk menunggu hingga build selesai.

Dapatkah saya menggunakan definisi build XAML dalam kebijakan cabang?

Tidak, Anda tidak dapat menggunakan definisi build XAML dalam kebijakan cabang.

Karakter wildcard apa yang dapat saya gunakan untuk peninjau kode yang diwajibkan?

Tanda bintang tunggal * cocok dengan sejumlah karakter, termasuk garis miring / ke depan dan garis miring terbelakang \. Tanda tanya ? cocok dengan satu karakter apa pun.

Contoh:

  • *.sql mencocokkan semua file dengan ekstensi .sql .
  • /ConsoleApplication/* cocok dengan semua file di bawah folder bernama ConsoleApplication.
  • /.gitattributes cocok dengan file.gitattributes* di akar repositori.
  • */.gitignoremencocokkan semua file .gitignore di repositori.

Apakah jalur peninjau kode yang diperlukan peka terhadap huruf besar atau kecil?

Tidak, kebijakan cabang tidak sensitif terhadap huruf besar/kecil.

Bagaimana cara mengonfigurasi beberapa pengguna sebagai peninjau yang diperlukan, tetapi hanya memerlukan salah satu dari mereka untuk menyetujui?

Anda dapat menambahkan pengguna ke grup, lalu menambahkan grup sebagai peninjau. Setiap anggota grup kemudian dapat menyetujui untuk memenuhi persyaratan kebijakan.

Saya memiliki izin untuk mengabaikan kebijakan. Mengapa saya masih melihat kegagalan kebijakan dalam status pull request?

Sistem selalu mengevaluasi kebijakan yang dikonfigurasi untuk perubahan permintaan pull. Untuk pengguna yang memiliki izin untuk melewati kebijakan, status kebijakan yang dilaporkan hanya bersifat informatif. Jika pengguna dengan izin bypass menyetujui, status kegagalan tidak memblokir penyelesaian permintaan pull.

Mengapa saya tidak dapat menyelesaikan permintaan pull saya sendiri saat saya mengatur "Izinkan pemohon untuk menyetujui perubahan mereka sendiri"?

Kebijakan Memerlukan Minimum Jumlah Peninjau dan Kebijakan Peninjau yang Disertakan Secara Otomatis memiliki opsi untuk Mengizinkan Pemohon Menyetujui Perubahan Mereka Sendiri. Dalam setiap kebijakan, pengaturan hanya berlaku untuk kebijakan tersebut. Pengaturan tidak memengaruhi kebijakan lain.

Misalnya, permintaan pull Anda memiliki kebijakan berikut yang ditetapkan:

  • Memerlukan jumlah minimum peninjau memerlukan setidaknya satu peninjau.
  • Peninjau yang disertakan secara otomatis memerlukan Anda atau tim Anda sebagai peninjau.
  • Peninjau yang disertakan secara otomatis memiliki fitur Izinkan pemohon menyetujui perubahan mereka sendiri yang diaktifkan.
  • Memerlukan jumlah minimum peninjau tidak mengaktifkan Izinkan pemohon untuk menyetujui perubahan mereka sendiri.

Dalam hal ini, persetujuan Anda memenuhi Peninjau yang ditambahkan secara otomatis, tetapi tidak memenuhi Persyaratan jumlah minimum peninjau, sehingga Anda tidak dapat menyelesaikan permintaan penarikan.

Kebijakan lain mungkin mencegah Anda menyetujui perubahan Anda sendiri, bahkan jika Izinkan pemohon menyetujui perubahan mereka sendiri diatur. Misalnya, Melarang pengguna yang terakhir melakukan push untuk menyetujui perubahannya sendiri.

Apa yang terjadi jika filter jalur tidak diawali dengan / atau wildcard?

Jalur dalam filter jalur yang tidak diawali dengan / atau karakter wildcard tidak memiliki efek. Filter jalur mengevaluasi seolah-olah jalur tersebut tidak ditentukan. Jalur seperti itu tidak dapat mencocokkan jalur file absolut yang dimulai dengan /.

Menggunakan AI untuk mengonfigurasi dan mengelola kebijakan cabang

Jika Anda mengonfigurasi Azure DevOps MCP Server, Anda dapat menggunakan bahasa alami untuk mengumpulkan konteks repositori, cabang, pull request, dan build sebelum memperbarui kebijakan cabang di Azure DevOps Services.

Server MCP Azure DevOps memerlukan Layanan Azure DevOps, mode agen di asisten AI Anda, dan Node.js 20.0+. Dokumentasi MCP saat ini tidak menjelaskan tindakan baca atau tulis kebijakan cabang langsung, jadi gunakan portal web Azure DevOps atau Azure DevOps CLI untuk membuat dan memperbarui kebijakan.

Tugas Contoh tanggapan
Menampilkan cabang dalam repositori List the branches in repo <Contoso.Web> in project <Contoso>
Meninjau permintaan pull sebelum memperketat kebijakan What pull requests require my review in project <Contoso>?
Periksa pull request dan item pekerjaan yang ditautkan Get details for pull request <67> and its linked work items in project <Contoso>
Periksa status kompilasi sebelum menjadikan validasi kompilasi sebagai persyaratan wajib Get the latest build status for pipeline <Contoso-CI> in project <Contoso>

Note

Jika Anda menggunakan Visual Studio Code, mode agen sangat membantu untuk mengumpulkan konteks proyek yang Anda butuhkan sebelum memperbarui kebijakan cabang.

Konten terkait

  • Last updated on