Zarządzanie żądaniami ściągnięcia

  • Artykuł

W tym artykule opisano sposób zarządzania żądaniami ściągnięcia w repozytorium PowerShell-Docs. Ten artykuł jest przeznaczony do pomocy w pracy dla członków zespołu PowerShell-Docs. Opublikowano ją tutaj, aby zapewnić przejrzystość procesów dla naszych współpracowników publicznych.

Najlepsze rozwiązania

  • Osoba przesyłająca żądanie ściągnięcia nie powinna scalać żądania ściągnięcia bez przeglądu elementu równorzędnego.
  • Przypisz recenzenta elementu równorzędnego po przesłaniu żądania ściągnięcia. Wczesne przypisanie pozwala recenzentowi odpowiedzieć wcześniej za pomocą uwag redakcyjnych.
  • Użyj komentarzy, aby opisać charakter zmiany lub typ żądanej recenzji. Pamiętaj o @mention recenzentze. Jeśli na przykład zmiana jest niewielka i nie potrzebujesz pełnego przeglądu technicznego, wyjaśnij to w komentarzu.

Kroki procesu żądania ściągnięcia

  1. Zapis: Tworzenie żądania ściągnięcia
  2. Składnik zapisywania: Przypisywanie recenzenta elementu równorzędnego
  3. Recenzent: elementy sprawdzające i komentarze (w razie potrzeby)
  4. Autor: dołączanie opinii dotyczących przeglądu
  5. Oba: Przegląd renderowania podglądu
  6. Oba elementy: Przeglądanie raportu weryfikacji — naprawianie ostrzeżeń i błędów
  7. Składnik zapisywania: Dodaj komentarz do logowania (dołącz informacje O Acrolinx)
  8. Recenzent: Oznacz recenzję jako "Zatwierdzono"
  9. Administrator repozytorium: Scal żądanie ściągnięcia (zobacz poniżej, aby zapoznać się z kryteriami)

Lista kontrolna recenzenta zawartości

Zobacz listę kontrolną redakcyjną , aby uzyskać bardziej kompleksową listę.

  • Język sprawdzający gramatykę, styl, zgodność, dokładność techniczną
  • Upewnij się, że przykłady nadal mają zastosowanie do wersji docelowej
  • Sprawdzanie renderowania podglądu
  • Sprawdź metadane — ms.date, usuń identyfikator ms.assetid, upewnij się, że wymagane pola
  • Weryfikowanie poprawności znaczników markdown
    • Zobacz przewodnik po stylu dotyczący reguł formatowania specyficznych dla zawartości
  • Zreorganizowanie przykładów w następujący sposób:
    • Zdania wprowadzające
    • Kod i dane wyjściowe
    • Szczegółowe wyjaśnienie kodu (w razie potrzeby)
  • Sprawdzanie dokładności hiperlinków
    • Zastępowanie lub usuwanie linków TechNet/MSDN
    • Upewnij się, że minimalna liczba przekierowań do miejsca docelowego
    • Upewnij się, że protokół HTTPS
    • Poprawny typ łącza
      • Linki do plików lokalnych
      • Linki adresu URL dla plików spoza zestawu dokumentów
    • Usuwanie ustawień regionalnych z adresów URL
    • Upraszczanie adresów URL wskazujących na docs.microsoft.com

Proces scalania gałęzi

Gałąź main jest jedyną gałęzią scaloną z gałęzią live. Scalania z gałęzi krótkotrwałych (roboczych) powinny być zgniecione.

Scalanie z/do release-branch main Live
gałąź robocza squash i scalanie squash i scalanie Niedozwolone
release-branch — Scalanie Niedozwolone
main Rebase — Scalanie

Lista kontrolna fuzji żądań ściągnięcia

  • Ukończono przegląd zawartości
  • Popraw gałąź docelową zmiany
  • Brak konfliktów scalania
  • Wszystkie kroki weryfikacji i kompilacji — powodzenie
    • Ostrzeżenia i sugestie powinny zostać naprawione (zobacz Uwagi dotyczące wyjątków)
    • Brak przerwanych łączy
  • Scal zgodnie z tabelą

Uwagi

Ostrzeżenia o następującej treści można zignorować:

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.

Po scaleniu żądania ściągnięcia nagłówek gałęzi docelowej zostanie zmieniony. Wszystkie otwarte żądania ściągnięcia oparte na poprzedniej usłudze HEAD są teraz nieaktualne. Nieaktualne żądanie ściągnięcia można scalić przy użyciu praw administratora w celu zastąpienia ostrzeżeń scalania w GitHub. Jest to bezpieczne, jeśli wcześniej scalone żądania ściągnięcia nie dotknęły tych samych plików. Kliknięcie przycisku Aktualizuj gałąź jest jednak najbezpieczniejszą opcją. Mogą wystąpić nierozwiązane konflikty, które muszą zostać naprawione.

Publikowanie na żywo

Okresowo zmiany skumulowane w gałęzi muszą być publikowane w main aktywnej witrynie internetowej.

  • Gałąź main jest scalona z live każdym dniem tygodnia o godzinie 15:00 PST.
  • Gałąź main powinna zostać scalona z live gałęzią po każdej znaczącej zmianie.
    • Zmiany w 50 lub większej ilości plików
    • Po scaleniu gałęzi wydania
    • Zmiany konfiguracji repozytorium lub zestawu dokumentów (docfx.json, konfiguracje platformy OPS, skrypty kompilacji itp.)
    • Zmiany w pliku przekierowania
    • Zmiany w dokumencie TOC
    • Po scaleniu gałęzi "project" (reorg zawartości, aktualizacji zbiorczej itp.)