Bagikan melalui

Kebijakan dan pengaturan cabang

  • Artikel

Layanan Azure DevOps | Azure DevOps Server 2022 - Azure DevOps Server 2019

Kebijakan cabang membantu tim melindungi cabang penting pengembangan mereka. Kebijakan memberlakukan kualitas kode tim Anda dan mengubah standar manajemen. Artikel ini menjelaskan cara mengatur dan mengelola kebijakan cabang. Untuk gambaran umum semua kebijakan dan pengaturan repositori dan cabang, lihat Pengaturan dan kebijakan repositori Git.

Cabang dengan kebijakan yang diperlukan yang dikonfigurasi tidak dapat dihapus, dan memerlukan permintaan pull (PR) untuk semua perubahan.

Prasyarat

  • Untuk mengatur kebijakan cabang, Anda harus menjadi anggota grup keamanan Administrator Proyek atau memiliki izin Edit kebijakan tingkat repositori. Untuk informasi selengkapnya, lihat Mengatur izin repositori Git.

Mengonfigurasi kebijakan cabang

Untuk mengelola kebijakan cabang, pilih Repos>Cabang untuk membuka halaman Cabang di portal web.

Cuplikan layar yang memperlihatkan item menu Cabang.

Anda juga dapat masuk ke pengaturan kebijakan cabang dengan Kebijakan Repositori>>Pengaturan>Proyek Nama> Cabang Kebijakan><Cabang.

Cabang yang memiliki kebijakan menampilkan ikon kebijakan. Anda dapat memilih ikon untuk langsung masuk ke pengaturan kebijakan cabang.

Untuk mengatur kebijakan cabang, temukan cabang yang ingin Anda kelola. Anda dapat menelusuri daftar atau mencari cabang Anda di kotak Nama cabang pencarian di kanan atas.

Pilih ikon Opsi lainnya di samping cabang, lalu pilih Kebijakan cabang dari menu konteks.

Cuplikan layar yang memperlihatkan Buka kebijakan cabang dari menu konteks.

Temukan cabang Anda di halaman. Anda dapat menelusuri daftar atau Anda dapat mencari cabang Anda menggunakan kotak Cari semua cabang di kanan atas.

Cuplikan layar yang memperlihatkan halaman Cabang.

Pilih tombol ... . Pilih Kebijakan cabang dari menu konteks.

Cuplikan layar yang memperlihatkan Buka kebijakan cabang dari menu konteks.

Konfigurasikan kebijakan pada halaman pengaturan cabang. Lihat bagian berikut untuk deskripsi dan instruksi untuk setiap jenis kebijakan.

Konfigurasikan kebijakan Anda di halaman Kebijakan . Lihat bagian berikut untuk deskripsi setiap jenis kebijakan. Pilih Simpan perubahan untuk menerapkan konfigurasi kebijakan baru Anda.

Cuplikan layar yang memperlihatkan tab Kebijakan.

Memerlukan jumlah minimum peninjau

Tinjauan kode penting untuk proyek pengembangan perangkat lunak. Untuk memastikan bahwa tim meninjau dan menyetujui PR, Anda dapat memerlukan persetujuan dari jumlah peninjau minimum. Kebijakan dasar mengharuskan sejumlah peninjau tertentu menyetujui kode, tanpa penolakan.

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 Aktifkan Memerlukan Tinjauan Kode.

  • Pilih Izinkan pemohon menyetujui perubahan mereka sendiri untuk memungkinkan pembuat PR memilih persetujuannya. Jika tidak, pembuat masih dapat memilih Setujui PR, tetapi suara mereka tidak dihitung terhadap jumlah minimum peninjau.

  • Pilih Melarang pendorong terbaru menyetujui perubahan mereka sendiri untuk memberlakukan pemisahan tugas. Secara default, siapa pun dengan izin pendorongan pada cabang sumber dapat menambahkan penerapan dan memberikan suara pada persetujuan PR. Memilih opsi ini berarti suara pendorong 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 disetujui.

  • Di bawah Saat perubahan baru didorong:
    • 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 setiap kali cabang sumber berubah, termasuk suara untuk menyetujui, menolak, atau menunggu.
  • 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 setiap kali cabang sumber berubah, termasuk suara untuk menyetujui, menolak, atau menunggu.

Centang kotak Perlu Tinjauan Kode

  • Jika Pemohon dapat menyetujui perubahan mereka sendiri tidak dipilih, pembuat permintaan pull masih dapat memilih Setujui permintaan pull mereka, tetapi suara mereka tidak dihitung terhadap Jumlah minimum peninjau.
  • Jika ada peninjau yang menolak perubahan, permintaan pull tidak dapat diselesaikan kecuali Anda memilih Izinkan penyelesaian meskipun beberapa peninjau memilih untuk menunggu atau menolak.
  • Anda dapat mengatur ulang suara peninjau kode saat perubahan baru didorong ke cabang sumber. Pilih Reset suara peninjau kode saat ada perubahan baru.

Jika semua kebijakan lain lolos, pembuat dapat menyelesaikan PR saat jumlah peninjau yang diperlukan menyetujuinya.

Periksa item kerja tertaut

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 tertaut ke Aktif. Pengaturan ini mengharuskan item kerja ditautkan ke PR agar PR 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.

Memerlukan item kerja tertaut dalam permintaan pull Anda

Periksa resolusi komentar

Kebijakan Periksa resolusi komentar memeriksa apakah semua komentar PR diselesaikan.

Konfigurasikan kebijakan resolusi komentar untuk cabang Anda dengan mengatur Periksa resolusi komentar ke Aktif. Kemudian pilih apakah akan membuat kebijakan Diperlukan atau Opsional.

Cuplikan layar Periksa resolusi komentar.

Untuk informasi selengkapnya tentang bekerja dengan komentar permintaan pull, lihat Meninjau permintaan pull.

Konfigurasikan kebijakan resolusi komentar untuk cabang Anda dengan memilih Periksa resolusi komentar.

Periksa resolusi komentar

Untuk informasi selengkapnya tentang bekerja dengan komentar permintaan pull, lihat Meninjau permintaan pull.

Batasi jenis penggabungan

Azure Repos memiliki beberapa strategi penggabungan, dan secara default, semuanya diizinkan. Anda dapat mempertahankan riwayat cabang yang konsisten dengan memberlakukan strategi penggabungan untuk penyelesaian PR.

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

Cuplikan layar Batasi jenis penggabungan.

  • Penggabungan dasar (tidak ada maju cepat) membuat penerapan penggabungan di target yang induknya adalah target dan cabang sumber.
  • Penggabungan squash membuat riwayat linier dengan satu penerapan di cabang target dengan perubahan dari cabang sumber. Pelajari selengkapnya tentang penggabungan squash dan pengaruhnya terhadap riwayat cabang.
  • Rebase dan fast-forward membuat riwayat linier dengan memutar ulang penerapan sumber ke cabang target tanpa penerapan penggabungan.
  • Rebase dengan penerapan penggabungan memutar ulang penerapan sumber ke target dan juga membuat penerapan penggabungan.

Catatan

Fitur ini tersedia untuk Azure DevOps Server 2020 dan versi yang lebih baru.

Menerapkan strategi penggabungan

Pertahankan riwayat cabang yang konsisten dengan memberlakukan strategi penggabungan saat permintaan pull selesai. Pilih Terakan strategi penggabungan dan pilih opsi untuk mengharuskan permintaan pull digabungkan menggunakan strategi tersebut.

Mengatur persyaratan penggabungan

  • Tidak ada penggabungan maju cepat - Opsi ini menggabungkan riwayat penerapan cabang sumber saat permintaan pull ditutup dan membuat penerapan penggabungan di cabang target.
  • Penggabungan squash - Selesaikan semua permintaan pull dengan penggabungan squash, membuat satu penerapan di cabang target dengan perubahan dari cabang sumber. Pelajari selengkapnya tentang penggabungan squash dan pengaruhnya terhadap riwayat cabang Anda.

Membuat validasi

Anda dapat mengatur kebijakan yang mengharuskan perubahan PR berhasil dibangun sebelum PR dapat diselesaikan. Kebijakan build mengurangi jeda dan menjaga hasil pengujian Anda tetap lolos. Kebijakan build membantu meskipun Anda menggunakan integrasi berkelanjutan (CI) di cabang pengembangan Anda untuk menangkap masalah lebih awal.

Kebijakan validasi build mengantrekan build baru saat PR baru dibuat atau perubahan didorong ke PR yang ada yang menargetkan cabang. Kebijakan build mengevaluasi hasil build untuk menentukan apakah PR dapat diselesaikan.

Penting

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

Untuk menambahkan kebijakan validasi build

  1. Pilih tombol di + samping Validasi build.

    Cuplikan layar yang memperlihatkan tombol Tambahkan di samping Validasi build.

  2. Isi formulir Tetapkan kebijakan build:

    Cuplikan layar pengaturan Kebijakan build.

    • Pilih alur Build.

    • Secara opsional atur filter Jalur. 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 masih memungkinkan PR selesai.

    • Atur kedaluwarsa build untuk memastikan pembaruan ke cabang anda yang dilindungi tidak merusak perubahan untuk PR terbuka.

      • Segera ketika <nama> cabang diperbarui: Opsi ini mengatur status kebijakan build PR gagal setiap kali cabang diperbarui, dan mengantre ulang build. Pengaturan ini memastikan bahwa perubahan PR berhasil dibangun meskipun cabang yang dilindungi berubah.

        Opsi ini paling cocok untuk tim yang cabang pentingnya memiliki beberapa perubahan. Tim yang bekerja di cabang pengembangan yang sibuk mungkin merasa terganggu untuk menunggu build setiap kali cabang diperbarui.

      • Setelah <n> jam jika <nama> cabang telah diperbarui: Opsi ini kedaluwarsa status kebijakan saat ini ketika cabang yang dilindungi diperbarui jika build yang lolos lebih lama dari ambang yang Anda masukkan. Opsi ini adalah kompromi antara selalu atau tidak pernah memerlukan build saat cabang yang 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.

  3. Pilih Simpan.

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

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

Catatan

Fitur ini tersedia untuk Azure DevOps Server 2020 dan versi yang lebih baru.

Tetapkan kebijakan yang memerlukan perubahan dalam permintaan pull untuk berhasil dibangun dengan cabang yang dilindungi sebelum permintaan pull dapat diselesaikan. Kebijakan build mengurangi jeda dan menjaga hasil pengujian Anda tetap lolos. Kebijakan build membantu meskipun Anda menggunakan integrasi berkelanjutan (CI) di cabang pengembangan Anda untuk menangkap masalah lebih awal.

Jika kebijakan validasi build diaktifkan, build baru diantrekan saat permintaan pull baru dibuat atau ketika perubahan didorong ke permintaan pull yang ada yang menargetkan cabang. Kebijakan build kemudian mengevaluasi hasil build untuk menentukan apakah permintaan pull dapat diselesaikan.

Penting

Sebelum menentukan kebijakan validasi build, Anda harus memiliki definisi build. Jika Anda tidak memilikinya, lihat Membuat definisi build dan memilih jenis build yang cocok dengan jenis proyek Anda.

Menambahkan kebijakan build

Pilih Tambahkan kebijakan build dan konfigurasikan opsi Anda di Tambahkan kebijakan build.

Pengaturan kebijakan build

  1. Pilih definisi Build.

  2. Pilih jenis Pemicu. Pilih Otomatis (setiap kali cabang sumber diperbarui) atau Manual.

  3. Pilih Persyaratan kebijakan. Jika Anda memilih Diperlukan, build harus berhasil diselesaikan untuk menyelesaikan permintaan pull. Pilih Opsional untuk memberikan pemberitahuan kegagalan build tetapi masih memungkinkan permintaan pull selesai.

  4. Atur kedaluwarsa build untuk memastikan bahwa pembaruan pada cabang anda yang dilindungi tidak merusak perubahan untuk permintaan pull terbuka.

    • Segera ketika branch name diperbarui: Opsi ini mengatur status kebijakan build dalam permintaan pull gagal saat cabang yang dilindungi diperbarui. Antre ulang build untuk merefresh status build. Pengaturan ini memastikan bahwa perubahan dalam permintaan pull berhasil dibangun bahkan saat cabang yang dilindungi berubah. Opsi ini paling baik untuk tim yang memiliki cabang penting dengan volume perubahan yang lebih rendah. Tim yang bekerja di cabang pengembangan yang sibuk mungkin merasa terganggu untuk menunggu build selesai setiap kali cabang yang dilindungi diperbarui.
    • Setelah n berjam-jam jika branch name telah diperbarui: Opsi ini kedaluwarsa status kebijakan saat ini ketika cabang yang dilindungi diperbarui jika build yang lolos lebih lama dari ambang batas yang dimasukkan. Opsi ini adalah kompromi antara selalu memerlukan build ketika cabang yang dilindungi diperbarui dan tidak pernah memerlukannya. Pilihan ini sangat baik untuk mengurangi jumlah build ketika cabang anda yang dilindungi memiliki pembaruan yang sering.
    • Tidak Pernah: Pembaruan pada cabang yang dilindungi tidak mengubah status kebijakan. Nilai ini mengurangi jumlah build untuk cabang Anda. Ini dapat menyebabkan masalah saat menutup permintaan pull yang tidak diperbarui baru-baru ini.

  5. 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 definisi build.

  6. Pilih Simpan.

Ketika pemilik mendorong perubahan yang berhasil dibangun, status kebijakan diperbarui. Jika Anda memiliki Segera saat branch name diperbarui atau Setelah n jam jika branch name telah memperbarui kebijakan build yang dipilih, status kebijakan akan diperbarui saat cabang yang dilindungi diperbarui jika build terbaru tidak lagi valid.

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 petunjuk tentang mengonfigurasi kebijakan ini, lihat Mengonfigurasi kebijakan cabang untuk layanan eksternal.

Memerlukan persetujuan dari layanan eksternal

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

Mewajibkan layanan eksternal untuk menyetujui

Untuk petunjuk tentang mengonfigurasi kebijakan ini, lihat Mengonfigurasi kebijakan cabang untuk layanan eksternal.

Secara otomatis menyertakan peninjau kode

Anda dapat secara otomatis menambahkan peninjau untuk menarik permintaan yang mengubah file di direktori dan file tertentu, atau ke semua permintaan pull dalam repositori.

  1. Pilih tombol di + samping Peninjau yang disertakan secara otomatis.

    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 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 pull.

  3. Pilih Simpan.

Catatan

Fitur ini tersedia untuk Azure DevOps Server 2020 dan versi yang lebih baru.

Pilih peninjau untuk direktori dan file tertentu di repositori Anda.

Masukkan jalur dan peninjau yang diperlukan

Peninjau ini secara otomatis ditambahkan ke permintaan pull yang mengubah file di sepanjang jalur tersebut. Anda juga dapat menentukan pesan umpan Aktivitas.

Menambahkan peninjau otomatis

Jika Anda memilih Diperlukan, permintaan pull tidak dapat diselesaikan hingga:

  • Setiap pengguna ditambahkan sebagai peninjau untuk jalur menyetujui perubahan.
  • Setidaknya satu orang di setiap grup ditambahkan ke jalur menyetujui perubahan.
  • Jumlah peninjau yang ditentukan untuk setiap grup yang ditambahkan ke jalur menyetujui perubahan.

Peninjau yang diperlukan ditambahkan secara otomatis

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

Anda dapat memilih Pemohon dapat menyetujui perubahan mereka sendiri.

Ketika semua peninjau yang diperlukan menyetujui kode, Anda dapat menyelesaikan permintaan pull.

Status permintaan pull menunjukkan bahwa peninjau telah disetujui

Melewati kebijakan cabang

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. Anda dapat mencakup izin bypass 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 saat mendorong berlaku untuk mendorong dari repositori lokal dan pengeditan yang dilakukan di web. Pengguna dengan izin ini dapat mendorong perubahan langsung ke cabang yang dilindungi tanpa memenuhi persyaratan kebijakan.

Cuplikan layar memperlihatkan izin penegakan kebijakan bypass.

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

Dalam TFS 2015 hingga TFS 2018 Update 2, izin Pengecualian dari penegakan kebijakan memungkinkan pengguna dengan izin ini untuk melakukan tindakan berikut:

  • Ikut serta untuk mengambil alih kebijakan dan menyelesaikan permintaan pull meskipun kumpulan kebijakan cabang saat ini tidak terpenuhi.
  • Dorong langsung ke cabang meskipun cabang tersebut memiliki kebijakan cabang yang ditetapkan. Ketika pengguna dengan izin ini melakukan pendorongan yang akan mengambil alih kebijakan cabang, pendorongan secara otomatis melewati kebijakan cabang tanpa langkah atau peringatan keikutsertaan.

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.

Filter jalur

Beberapa kebijakan cabang menawarkan filter jalur. Jika filter jalur diatur, kebijakan hanya berlaku untuk file yang cocok dengan filter jalur. Membiarkan bidang ini kosong berarti bahwa kebijakan berlaku untuk semua file di cabang.

Anda dapat menentukan jalur absolut (jalur harus dimulai baik oleh / atau kartubebas) dan kartubebas. Contoh:

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

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

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

Jalur yang diawali dengan ! dikecualikan jika tidak akan 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. Filter diterapkan kiri-ke-kanan.

T & J

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

Anda tidak dapat mendorong perubahan langsung ke cabang dengan kebijakan cabang yang diperlukan kecuali Anda memiliki izin untuk melewati kebijakan cabang. Perubahan pada cabang ini hanya dapat dilakukan 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?

Tarik permintaan ke cabang dengan kebijakan cabang yang dikonfigurasi memiliki tombol Atur lengkapi otomatis. Pilih opsi ini untuk menyelesaikan permintaan pull secara otomatis setelah memenuhi semua kebijakan. Pelengkapan otomatis berguna saat Anda tidak mengharapkan masalah dengan perubahan Anda.

Kapan kondisi kebijakan cabang diperiksa?

Kebijakan cabang mengevaluasi kembali di server ketika pemilik permintaan pull mendorong perubahan dan ketika peninjau memilih. 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 kartubebas apa yang dapat saya gunakan untuk peninjau kode yang diperlukan?

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

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.
  • */.gitignorecocok dengan file .gitignore apa pun di repositori.

Apakah jalur peninjau kode yang diperlukan peka huruf besar/kecil?

Tidak, kebijakan cabang tidak peka 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 kebijakan bypass. Mengapa saya masih melihat kegagalan kebijakan dalam status permintaan pull?

Kebijakan yang dikonfigurasi selalu dievaluasi untuk perubahan permintaan pull. Untuk pengguna yang memiliki izin kebijakan bypass, status kebijakan yang dilaporkan hanya saran. Jika pengguna dengan izin bypass menyetujui, status kegagalan tidak memblokir penyelesaian permintaan pull.

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

Kebijakan Memerlukan jumlah minimum 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 mengharuskan Anda atau tim tempat Anda berada sebagai peninjau.
  • Peninjau yang disertakan secara otomatis memiliki Izinkan pemohon untuk 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 disertakan secara otomatis, tetapi tidak Memerlukan jumlah minimum peninjau, sehingga Anda tidak dapat menyelesaikan permintaan pull.

Mungkin juga ada kebijakan lain, seperti Melarang pendorong terbaru menyetujui perubahan mereka sendiri, yang mencegah Anda menyetujui perubahan Anda sendiri bahkan jika Izinkan pemohon menyetujui perubahan mereka sendiri ditetapkan.

Apa yang terjadi ketika jalur dalam filter jalur tidak dimulai dengan / atau dengan kartubebas?

Jalur dalam filter jalur yang tidak dimulai dengan / atau dengan kartubebas tidak berpengaruh, dan filter jalur mengevaluasi seolah-olah jalur tersebut tidak ditentukan. Jalur seperti itu tidak dapat mencocokkan / jalur file absolut dimulai dengan.