Sdílet prostřednictvím

Správa pull requestů

  • Článek

Tento článek popisuje, jak spravujeme pull requesty v úložišti PowerShell-Docs. Tento článek je navržený tak, aby byl pracovní pomůckou pro členy PowerShell-Docs týmu. Tyto informace zde publikujeme, abychom zajistili transparentnost procesů pro naše veřejné přispěvatele.

Osvědčené postupy

  • Požádejte o revizi. Osoba, která žádost o přijetí změn odesílá, by neměla sloučit žádost o přijetí změn bez partnerské kontroly.
  • Přiřaďte recenzenta při odeslání žádosti o změnu. Včasné přiřazení umožňuje recenzentovi dříve poskytnout redakční poznámky.
  • Pomocí komentářů popište povahu odesílané změny. Pokud je například změna menší, vysvětlete změnu a nepotřebujete úplnou technickou kontrolu. Nezapomeňte na @mention posuzovatele.
  • Pomocí funkce pro návrhy komentářů můžete autorovi usnadnit přijetí navrhované změny. Další informace najdete v tématu Kontrola navrhovaných změn v pull requestu.

Kroky procesu schvalování PR

  1. Autor: Vytvořit PR
    • Vyplňte šablonu PR
    • Napojte jakékoli problémy vyřešené žádostí o přijetí změn (PR)
    • K zavření problému použijte funkci automatického zaclose GitHubu.
    • Projděte si jednotlivé položky v kontrolním seznamu a odškrtněte je.
  2. Autor: Přiřadit recenzenta
  3. Recenzent: provádí korektury a komentáře (podle potřeby)
  4. Autor: Začlenit zpětnou vazbu z recenze
  5. Obojí: Kontrola vykreslování ve verzi Preview
  6. Obě: Zkontrolovat sestavu ověření, opravit upozornění a chyby
  7. Recenzent: Označte recenzi jako "Schválenou"
  8. Správce úložiště: Sloučení pull requestu

Kontrolní seznam revidujících obsahu

Podrobnější seznam najdete v redakčním kontrolním seznamu .

  • Kontrola pravopisu pro gramatiku, styl, zřetězení, technickou přesnost
  • Ujistěte se, že příklady stále platí pro cílovou verzi.
  • Zkontrolujte vykreslování náhledu
  • Kontrola metadat – ms.date, odebrání ms.assetid, zajištění požadovaných polí
  • Ověření správnosti markdownu
    • Viz průvodce stylem pro pravidla formátování specifická pro obsah.
  • Přeuspořádat příklady následujícím způsobem:
    • Úvodní odstavec
    • Kód a výstup
    • Podrobné vysvětlení kódu (podle potřeby)
  • Kontrola přesnosti hypertextových odkazů
    • Nahrazení nebo odebrání odkazů TechNet/MSDN
    • Zajištění minimálního počtu přesměrování na cíl
    • Zajistěte HTTPS
    • Správný typ propojení
      • Odkazy na soubory pro místní soubory
      • URL odkazy na soubory mimo sadu dokumentace
    • Odstranit lokality z adres URL
    • Zjednodušení adres URL odkazující na learn.microsoft.com
  • Ověření správnosti verze obsahu ve všech verzích

Proces sloučení větví

Větev main je jediná větev, do které by se měla sloučit live. Sloučení z krátkodobých (pracovních) větví by měla být zmáčkována před sloučením do main.

Sloučit z/do release-branch main živé vysílání
pracovní větev sloučit a spojit squash and merge Nepovoleno
release-branch — sloučit Nepovoleno
main změna základu — sloučit

Kontrolní seznam pro sloučení žádostí o přijetí změn

  • Kontrola obsahu je dokončená.
  • Správná cílová větev pro změnu
  • Žádné konflikty při slučování
  • Všechny kontroly a kroky sestavení proběhly úspěšně
  • Sloučit podle tabulky

Poznámky

Následující upozornění je možné ignorovat:

Can't find service name for `<version>/<modulepath>/About/About.md`

Metadata with following name(s) are not allowed to be set in YAML header, or as file level
metadata in docfx.json, or as global metadata in docfx.json: `locale`. They are generated by
Docs platform, so the values set in these 3 places will be ignored. Please remove them from all
3 places to resolve the warning.

Při sloučení PR se změní HEAD cílové větve. Všechny otevřené pull requesty, které byly založeny na předchozím HEAD, jsou nyní zastaralé. Správce projektu má potřebné právo k přepsání varování o sloučení a ke sloučení zastaralé žádosti o přijetí změn (PR) na GitHubu. Sloučení zastaralé žádosti o přijetí změn je bezpečné, pokud se dříve sloučené žádosti o přijetí změn nedotkly stejných souborů.

Pokud chcete aktualizovat pull request, vyberte tlačítko Aktualizovat větev. Zvolte možnost Aktualizovat s rebase. Další informace najdete v tématu Aktualizace větve pull requestu.

Publikování do služby Live

Pravidelně se změny kumulované ve main větvi musí publikovat na živém webu.

  • Větev main se sloučí do live každého dne v týdnu ve 3:00 PST.
  • Větev main by se měla sloučit do live po jakékoli významné změně.
    • Změny ve více než 50 souborech
    • Po sloučení vydávací větve
    • Změny konfigurace úložiště nebo sady docset (docfx.json, konfigurace OPS, skripty sestavení atd.)
    • Změny v souboru přesměrování
    • Změny obsahu
    • Po sloučení větve "projekt" (přeorganizování obsahu, hromadná aktualizace atd.)