Bagikan melalui


Cara mengirimkan permintaan tarik

Untuk membuat perubahan pada konten, kirim permintaan pull (PR) dari fork Anda. Permintaan penggabungan harus ditinjau sebelum dapat digabungkan. Untuk hasil terbaik, tinjau daftar periksa editorial sebelum mengirimkan permintaan penarikan Anda.

Menggunakan cabang Git

Cabang main adalah cabang bawaan untuk PowerShell-Docs. Perubahan yang dilakukan dalam cabang kerja digabungkan ke cabang main sebelum kemudian diterbitkan. Cabang main digabungkan ke cabang live setiap hari kerja pada pukul 15.00 (Waktu Pasifik). Cabang live berisi konten yang diterbitkan ke learn.microsoft.com.

Sebelum memulai perubahan apa pun, buat cabang kerja di salinan lokal repositori PowerShell-Docs Anda. Saat bekerja secara lokal, pastikan untuk menyinkronkan repositori lokal Anda sebelum membuat cabang kerja Anda. Cabang kerja harus dibuat dari salinan up-to-date cabang main.

Semua pull request harus menargetkan cabang main. Jangan mengirimkan perubahan ke cabang live. Perubahan yang dilakukan di cabang main dimasukkan ke dalam live, menggantikan perubahan apa pun yang dilakukan pada live.

Membuat proses pull request menjadi lebih efektif untuk semua orang

Semakin sederhana dan lebih fokus Anda dapat membuat PR Anda, semakin cepat dapat ditinjau dan digabungkan.

Hindari permintaan pull yang memperbarui file dalam jumlah besar atau berisi perubahan yang tidak terkait

Hindari membuat PR yang berisi perubahan yang tidak terkait. Pisahkan pembaruan kecil ke artikel yang ada dari artikel baru atau penulisan ulang utama. Kerjakan perubahan ini di cabang kerja terpisah.

Perubahan dalam jumlah besar menghasilkan PR dengan banyak file yang diubah. Batasi PR Anda hingga maksimum 50 file yang diubah. PR besar sulit ditinjau dan lebih rentan terhadap kesalahan.

Mengganti nama atau menghapus file

Harus ada masalah yang terkait dengan PR saat Anda mengganti nama atau menghapus file. Masalah tersebut harus membahas kebutuhan untuk mengganti nama atau menghapus file.

Hindari mencampur penambahan konten atau perubahan dengan penggantian nama dan penghapusan file. File apa pun yang Anda ganti nama atau hapus harus ditambahkan ke file pengalihan yang sesuai. Jika memungkinkan, perbarui file apa pun yang ditautkan ke konten yang diganti namanya atau dihapus, termasuk file TOC apa pun.

Hindari mengedit file konfigurasi repositori

Hindari memodifikasi file konfigurasi repositori. Batasi perubahan Anda jika memungkinkan untuk file konten Markdown dan file gambar pendukung apa pun yang diperlukan untuk konten.

Modifikasi yang salah pada file konfigurasi repositori dapat merusak build, memperkenalkan kerentanan atau masalah aksesibilitas, atau melanggar standar organisasi. File konfigurasi repositori adalah file apa pun yang cocok dengan satu atau beberapa pola ini:

  • *.yml
  • .github/**
  • .localization-config
  • .openpublishing*
  • LICENSE*
  • reference/docfx.json
  • reference/mapping/**
  • tests/**
  • ThirdPartyNotices
  • tools/**

Untuk keamanan dan keselamatan, jangan ubah file-file ini. Jika Menurut Anda salah satu file ini harus diubah, ajukan masalah. Setelah pengelola melakukan triase masalah, mereka akan membuat perubahan yang sesuai.

Menggunakan templat PR

Saat Anda membuat PR, sebuah templat secara otomatis akan dimasukkan ke dalam badan PR untuk Anda. Sepertinya ini:

# PR Summary

<!--
    Delete this comment block and summarize your changes and list
    related issues here. For example:

    This changes fixes problem X in the documentation for Y.

    - Fixes #1234
    - Resolves #1235
-->

## PR Checklist

<!--
    These items are mandatory. For your PR to be reviewed and merged,
    ensure you have followed these steps. As you complete the steps,
    check each box by replacing the space between the brackets with an
    x or by clicking on the box in the UI after your PR is submitted.
-->

- [ ] **Descriptive Title:** This PR's title is a synopsis of the changes it proposes.
- [ ] **Summary:** This PR's summary describes the scope and intent of the change.
- [ ] **Contributor's Guide:** I have read the [contributors guide][contrib].
- [ ] **Style:** This PR adheres to the [style guide][style].

<!--
    If your PR is a work in progress, please mark it as a draft or
    prefix it with "(WIP)" or "WIP:"

    This helps us understand whether or not your PR is ready to review.
-->

[contrib]: /powershell/scripting/community/contributing/overview
[style]: /powershell/scripting/community/contributing/powershell-style-guide

Di bagian "Ringkasan PR", tulis ringkasan singkat perubahan Anda dan cantumkan masalah terkait dengan nomor masalahnya, seperti #1234. Jika PR Anda memperbaiki atau mengatasi masalah, gunakan fitur autoclose GitHub sehingga masalah ditutup secara otomatis saat PR Anda digabungkan.

Tinjau item di bagian "Daftar Periksa PR" dan beri tanda centang setelah Anda menyelesaikan masing-masing item. Anda harus mengikuti petunjuk dan memeriksa setiap item agar tim menyetujui PR Anda.

Jika PR Anda adalah pekerjaan yang sedang berlangsung, atur ke mode draf atau awali judul PR Anda dengan WIP.

Komentar Ekspektasi

Setelah Anda mengirimkan PR, bot akan mengomentari PR Anda. Komentar menyediakan sumber daya dan menetapkan harapan untuk sisa proses. Kami mungkin memperbarui komentar ini secara berkala, jadi selalu tinjau komentar, meskipun ini bukan kontribusi pertama Anda.

contoh komentar harapan

Layanan validasi Docs PR

Layanan validasi Docs PR adalah aplikasi GitHub yang menjalankan aturan validasi pada perubahan Anda. Anda harus memperbaiki kesalahan atau peringatan yang dilaporkan oleh layanan validasi.

Langkah-langkah berikut menguraikan perilaku validasi:

  1. Anda mengirimkan PR.

  2. Dalam komentar GitHub yang menunjukkan status dari 'pemeriksaan' yang diaktifkan pada repositori. Dalam contoh ini, ada dua pemeriksaan yang diaktifkan, "Terapkan Validasi" dan "OpenPublishing.Build":

    status validasi - beberapa pemeriksaan gagal

    Build dapat lulus meskipun validasi commit gagal.

  3. Pilih Detail untuk informasi selengkapnya. Halaman Detail memperlihatkan semua pemeriksaan validasi yang gagal dan menyertakan informasi tentang cara memperbaiki masalah.

  4. Ketika validasi berhasil, komentar berikut ditambahkan ke PR:

    Status validasi: berhasil

Nota

Jika Anda adalah kontributor eksternal (bukan karyawan Microsoft), Anda tidak memiliki akses ke laporan build terperinci atau tautan pratinjau.

Saat PR ditinjau, Anda mungkin diminta untuk membuat perubahan atau memperbaiki pesan peringatan validasi. Tim PowerShell-Docs dapat membantu Anda memahami kesalahan validasi dan persyaratan editorial.

Tindakan GitHub

Beberapa GitHub Actions yang berbeda dijalankan pada perubahan Anda untuk memvalidasi dan memberikan konteks bagi Anda serta peninjau.

Verifikasi daftar periksa

Jika PR Anda tidak dalam mode draf dan tidak diawali dengan WIP, aksi GitHub akan memeriksa PR Anda untuk memastikan Anda telah memilih setiap item dalam daftar periksa templat PR. Pengelola tidak akan meninjau atau menggabungkan PR Anda hingga Anda menyelesaikan checklist. Semua item dalam daftar periksa adalah wajib.

Verifikasi otorisasi

Jika PR Anda menargetkan live cabang atau memodifikasi file konfigurasi repositori apa pun, sebuah GitHub Action memeriksa izin Anda untuk memastikan bahwa Anda berwenang melakukan perubahan tersebut.

Hanya administrator repositori yang berwenang untuk menargetkan live cabang atau memodifikasi file konfigurasi repositori.

Pelaporan perubahan konten versi

Jika PR Anda menambahkan, menghapus, atau memodifikasi konten versi apa pun, GitHub Action menganalisis perubahan Anda dan menulis laporan yang meringkas jenis perubahan yang dibuat pada konten berversi.

Laporan ini dapat menunjukkan apakah ada versi lain dari file yang perlu Anda perbarui dalam PR ini.

Untuk menemukan laporan konten versi untuk PR Anda:

  1. Memilih tab "Pemeriksaan" pada halaman PR Anda.
  2. Pilih pekerjaan "Pelaporan" dari daftar pekerjaan.
  3. Pilih "..." di kanan atas.
  4. Pilih "Lihat ringkasan pekerjaan."

Contoh laporan perubahan konten versi

Langkah berikutnya

panduan gayaPowerShell-Docs

Sumber daya tambahan

Cara kami mengelola permintaan pull