Jak odesílat pull requesty

Pokud chcete provést změny obsahu, odešlete žádost o přijetí změn (PR) ze svého forku. Žádost o přijetí změn musí být před sloučením zkontrolována. Nejlepších výsledků dosáhnete tak, že před odesláním žádosti o přijetí změn zkontrolujete redakční kontrolní seznam .

Použití větví Gitu

Výchozí větev pro PowerShell-Docs je main větev. Změny provedené v pracovních větvích se před publikováním sloučí do main větve. Větev main se slučuje do větve live každý pracovní den v 15:00 (pacifického času). Větev live obsahuje obsah publikovaný do learn.microsoft.com.

Před zahájením jakýchkoli změn vytvořte pracovní větev v místní kopii úložiště PowerShell-Docs. Při práci místně nezapomeňte před vytvořením pracovní větve synchronizovat místní úložiště. Pracovní větev by měla být vytvořena z kopií větve main up-tos datumem.

Všechny žádosti o přijetí změn by měly směřovat na větev main. Neodesílejte změny do live větve. Změny provedené ve větvi main se sloučí do live, což přepíše všechny změny provedené ve větvi live.

Vylepšení procesu pull requestů pro všechny

Čím jednodušší a konkrétnější může být váš pull request, tím rychleji může být zkontrolován a sloučen.

Vyhněte se žádostem o přijetí změn, které aktualizují velký počet souborů nebo obsahují nesouvisející změny.

Vyhněte se vytváření pull requestů obsahujících nesouvisející změny. Oddělte dílčí aktualizace stávajících článků od nových článků nebo hlavních přepisů. Pracujte na těchto změnách v samostatných pracovních větvích.

Hromadné změny vytvářejí PR s velkým počtem změněných souborů. Omezte PR požadavky na maximálně 50 změněných souborů. Velké žádosti o přijetí změn se obtížně kontrolují a jsou náchylnější k chybám.

Přejmenování nebo odstranění souborů

S přejmenováním nebo odstraněním souborů musí být spojena určitá potíž s PR (pull request). Je nutné prodiskutovat potřebu přejmenování nebo odstranění souborů.

Vyhněte se kombinování přidávání obsahu nebo změn s přejmenováním a odstraňováním souborů. Všechny soubory, které přejmenujete nebo odstraníte, musí být přidány do příslušného souboru přesměrování. Pokud je to možné, aktualizujte všechny soubory, které odkazují na přejmenovaný nebo odstraněný obsah, včetně souborů TOC.

Vyhněte se úpravám konfiguračních souborů úložiště.

Vyhněte se úpravám konfiguračních souborů úložiště. Pokud je to možné, omezte změny na soubory obsahu Markdownu a všechny podpůrné soubory obrázků potřebné pro obsah.

Nesprávné úpravy konfiguračních souborů úložiště můžou přerušit sestavení, zavést chyby zabezpečení nebo problémy s přístupností nebo narušit standardy organizace. Konfigurační soubory úložiště jsou všechny soubory, které odpovídají jednomu nebo více z těchto vzorů:

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

Kvůli bezpečnosti a zabezpečení tyto soubory neměňte. Pokud si myslíte, že jeden z těchto souborů by se měl změnit, vytvořte problém. Po vyřešení problému správci provedou příslušné změny.

Použijte šablonu pro Pull Request

Při vytváření žádosti o přijetí změn se šablona automaticky vloží do textu žádosti o přijetí změn. Vypadá takto:

# 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

V části Souhrn PR napište krátký souhrn změn a uveďte všechny související problémy podle jejich čísla problému, například #1234. Pokud vaše PR opraví nebo vyřeší problém, použijte funkci automatického uzavření GitHubu, aby se problém po sloučení PR automaticky zavřel.

Zkontrolujte položky v sekci "PR Kontrolní seznam" a při dokončení každého z nich je zaškrtněte. Aby tým schválil vaši žádost o úpravy, musíte postupovat podle pokynů a zkontrolovat každou položku.

Pokud je váš pull request ve fázi rozpracování, nastavte ho na režim konceptu nebo k názvu pull requestu přidejte předponu WIP.

Komentář k očekáváním

Po odeslání vašeho PR robot vloží komentář. Komentář poskytuje prostředky a nastavuje očekávání pro zbytek procesu. Tento komentář můžeme pravidelně aktualizovat, takže si ho vždy projděte, i když to není váš první příspěvek.

Ověřovací služba pro PR v Docs

Ověřovací služba změn PR Docs je aplikace GitHub, která spouští validační pravidla pro vaše změny. Všechny chyby nebo upozornění hlášené ověřovací službou musíte opravit.

Následující kroky popisují chování ověřování:

1. Odešlete žádost o přijetí změn.

2. V komentáři GitHubu, který označuje stav "kontrol" povolených v úložišti. V tomto příkladu jsou povolené dvě kontroly: Ověření potvrzení a OpenPublishing.Build:

   

   Sestavení může projít i v případě, že ověření potvrzení selže.

3. Další informace získáte výběrem Podrobnosti. Na stránce Podrobnosti se zobrazují všechny kontroly ověření, které selhaly, a obsahuje informace o tom, jak tyto problémy opravit.

4. Po úspěšném ověření se do žádosti o přijetí změn přidá následující komentář:

   

Poznámka:

Pokud jste externí přispěvatel (ne zaměstnanec Microsoftu), nemáte přístup k podrobným sestavám sestavení nebo odkazům na náhled.

Když je žádost o začlenění kontrolována, můžete být požádáni o úpravy nebo opravu varovných zpráv ověření. Tým PowerShell-Docs vám může pomoct pochopit chyby ověřování a redakční požadavky.

Akce na GitHubu

Na vaše změny je spuštěno několik různých GitHub Actions, které mají za účel ověřit a poskytnout kontext pro vás i pro recenzenty.

Ověření kontrolního seznamu

Pokud vaše žádost o přijetí změn není v režimu konceptu a nemá předponu WIP, GitHub Action zkontroluje vaši žádost a ověří, zda jste vybrali všechny položky v kontrolním seznamu šablony žádosti o přijetí změn. Maintaineři váš PR nebudou přezkoumávat ani slučovat, dokud nedokončíte kontrolní seznam. Položky kontrolního seznamu jsou povinné.

Ověření autorizace

Pokud váš pull request cílí na live větev nebo upravuje nějaké konfigurační soubory úložiště, akce na GitHubu zkontroluje vaše oprávnění, aby ověřila, že jste oprávněni tyto změny odeslat.

K cílení na větev nebo úpravě live konfiguračních souborů úložiště mají oprávnění pouze správci úložiště.

Hlášení změn verzovaného obsahu

Pokud vaše žádost o přijetí změn přidá, odebere nebo upraví jakýkoli verzovaný obsah, GitHub Action analyzuje vaše změny a zapíše sestavu se souhrnem typů změn provedených ve verzovaném obsahu.

Tato zpráva může zobrazit, jestli existují jiné verze souborů, které potřebujete aktualizovat v tomto pull requestu.

Pro vyhledání zprávy o verzovaném obsahu pro váš pull request:

1. Výběr karty "Checks" na PR stránce.
2. V seznamu úloh vyberte úlohu "Vytváření sestav".
3. Vyberte "..." v pravém horním rohu.
4. Vyberte Zobrazit souhrn úloh.

Další kroky

Stylistická příručkaPowerShell-Docs

Další zdroje informací

Jak spravujeme pull requesty