Udostępnij za pomocą

Zarządzanie pull requestami

W tym artykule dokumentujemy, jak zarządzamy żądaniami pull w repozytorium PowerShell-Docs. Ten artykuł jest przeznaczony do pomocy w pracy dla członków zespołu PowerShell-Docs. Publikujemy te informacje tutaj, aby zapewnić przejrzystość procesu dla naszych publicznych współautorów.

Najlepsze rozwiązania

  • Zażądaj przeglądu. Osoba przesyłająca pull request nie powinna scalić pull request bez przeglądu kodu.
  • Przypisz recenzenta równorzędnego po przesłaniu żądania ściągnięcia. Wczesne przypisanie pozwala recenzentowi wcześniej odpowiedzieć z uwagami edytorskimi.
  • Użyj komentarzy, aby opisać charakter przesłanej zmiany. Jeśli na przykład zmiana jest niewielka, wyjaśnij zmianę i nie potrzebujesz pełnej przeglądu technicznego. Upewnij się, że @mention recenzent sprawdzi.
  • Użyj funkcji sugestii komentarza, aby ułatwić autorowi akceptowanie sugerowanej zmiany. Aby uzyskać więcej informacji, zobacz Przeglądanie proponowanych zmian w prośbie o ściągnięcie.

Kroki procesu żądania ściągnięcia

  1. Autor: Utwórz żądanie zatwierdzenia
    • Wypełnij szablon PR
    • Połącz wszelkie problemy rozwiązane przez pull request
    • Aby zamknąć problem, użyj funkcji autoclose w usłudze GitHub
    • Przepracuj i zaznacz każdy element na liście kontrolnej
  2. Autor: Przypisz recenzenta koleżeńskiego
  3. Recenzent: dokonuje korekt i dodaje komentarze (w razie potrzeby)
  4. Autor: uwzględnij uwagi z recenzji
  5. Oba: Podgląd renderowania
  6. Oba: Przeglądanie raportu weryfikacji — naprawianie ostrzeżeń i błędów
  7. Recenzent: Oznacz recenzję "Zatwierdzono"
  8. Konserwator repozytorium: scal żądanie ściągnięcia

Lista kontrolna recenzenta zawartości

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

  • Sprawdź poprawność gramatyki, styl, zwięzłość i dokładność techniczną
  • Upewnij się, że przykłady nadal mają zastosowanie do wersji docelowej
  • Sprawdź renderowanie podglądu
  • Sprawdź metadane — „ms.date”, usuń identyfikator „ms.assetid”, sprawdź, czy pola wymagane
  • 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:
    • Akapit wprowadzający
    • Kod i dane wyjściowe
    • Szczegółowe wyjaśnienie kodu (w razie potrzeby)
  • Sprawdzanie hiperlinków pod kątem dokładności
    • Zastępowanie lub usuwanie linków TechNet/MSDN
    • Upewnij się, że minimalna liczba przekierowań do miejsca docelowego
    • Upewnij się, że używasz HTTPS
    • Poprawny typ łącza
      • Linki do plików lokalnych
      • Linki adresów URL dla plików spoza zestawu dokumentów
    • Usuwanie ustawień regionalnych z adresów URL
    • Upraszczanie adresów URL wskazujących na learn.microsoft.com
  • Sprawdź, czy wersjonowana zawartość jest poprawna we wszystkich wersjach

Proces scalania gałęzi

Gałąź main jest jedyną gałęzią, która powinna zostać scalona z gałęzią live. Scalania z gałęzi krótkożytnych (roboczych) powinny zostać zgniecione przed scaleniem z main.

Łącz z/do release-branch główny mieszkać
gałąź robocza squash i scalanie squash i scalanie Niedozwolone
release-branch — Łączenie Niedozwolone
główny Rebase — Łączenie

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 zostały pomyślnie zakończone.
    • Ostrzeżenia i sugestie powinny zostać naprawione (zobacz Uwagi dotyczące wyjątków)
    • Brak uszkodzonych łączy
    • Akcja Lista kontrolna została uruchomiona i zakończona pomyślnie
    • Jeśli została wyzwolona kontrola autoryzacji, zakończyła się pomyślnie.
  • Połącz według tabeli

Notatki

Następujące ostrzeżenia 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 pull requestu HEAD docelowej gałęzi zostanie zmieniony. Wszystkie otwarte pull requesty, które opierały się na poprzednim HEAD, są teraz nieaktualne. Opiekun ma właściwe uprawnienia, aby zastąpić ostrzeżenia scalania i scalić nieaktualny PR w usłudze GitHub. Scalanie nieaktualnej prośby o połączenie jest bezpieczne, jeśli wcześniej scalone prośby o połączenie nie dotyczyły tych samych plików.

Aby zaktualizować żądanie ściągnięcia, wybierz przycisk Aktualizuj gałąź. Wybierz opcję Aktualizuj przez rebase. Aby uzyskać więcej informacji, zobacz Aktualizowanie gałęzi pull requestu.

Publikowanie na żywo

Okresowo zmiany skumulowane w gałęzi należy publikować na żywej stronie internetowej main.

  • Gałąź main scala się z live w każdy dzień roboczy o godzinie 15:00 czasu PST.
  • Po każdej znaczącej zmianie gałąź main powinna zostać scalona z live.
    • Zmiany dotyczące 50 lub więcej 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 spisie treści
    • Po połączeniu gałęzi "projekt" (reorganizacja zawartości, masowa aktualizacja itp.)
  • Last updated on