Przepływ pracy dotyczący współtworzenia dokumentacji w usłudze GitHub: istotne lub długotrwałe zmianyGitHub contribution workflow for major or long-running changes

Ważne

W przypadku wszystkich repozytoriów publikowanych w witrynie docs.microsoft.com stosowany jest Kodeks postępowania firmy Microsoft dotyczący rozwiązań typu open source lub Kodeks postępowania organizacji .NET Foundation.All repositories that publish to docs.microsoft.com have adopted either the Microsoft Open Source Code of Conduct or the .NET Foundation Code of Conduct. Aby uzyskać więcej informacji, zobacz często zadawane pytania dotyczące kodu postępowania.For more information, see the Code of Conduct FAQ. W przypadku pytań lub komentarzy możesz też napisać na adres opencode@microsoft.com lub conduct@dotnetfoundation.org.Or contact opencode@microsoft.com, or conduct@dotnetfoundation.org with any questions or comments.

Drobne poprawki lub wyjaśnienia dotyczące dokumentacji i przykładów kodu w repozytoriach publicznych znajdują się w Warunkach korzystania z witryny docs.microsoft.com.Minor corrections or clarifications to documentation and code examples in public repositories are covered by the docs.microsoft.com Terms of Use. Nowe lub ważne zmiany spowodują wygenerowanie komentarza w żądaniu ściągnięcia z prośbą o przesłanie internetowej umowy licencyjnej współautorstwa (CLA), jeśli nie jesteś pracownikiem firmy Microsoft.New or significant changes will generate a comment in the pull request, asking you to submit an online Contribution License Agreement (CLA) if you are not an employee of Microsoft. Zanim scalimy żądanie ściągnięcia, musisz wypełnić formularz online.You will need to complete the online form before your pull request can be merged.

OmówienieOverview

Ten przepływ pracy jest przeznaczony dla współautorów, którzy muszą wprowadzić istotne zmiany lub będą często tworzyć dokumentację w repozytorium.This workflow is suitable for a contributor who needs to make a major change or will be a frequent contributor to a repository. Współautorzy, którzy często tworzą dokumentację, zwykle dokonują trwałych lub długookresowych zmian, które przechodzą wiele cykli kompilacji, weryfikacji i przemieszczania lub trwają wiele dni przed wyrejestrowaniem i scaleniem żądania ściągnięcia.Frequent contributors typically have ongoing (long-running) changes, which go through multiple build/validation/staging cycles or span multiple days before pull request sign-off and merge.

Przykłady tego typu zmian to:Examples of these types of contributions include:

  • Wprowadzenie wielu zmian.Making a large contribution. Przykładowo można wprowadzać zmiany zawartości (dodawania, modyfikowania lub usuwania) obejmujące wiele artykułów, które muszą zostać zatwierdzone i przetestowane jako jedna jednostka pracy w ramach jednego żądania ściągnięcia.For instance, you might make contributions (additions, changes, or deletions) that span multiple articles and need to be committed and tested as one unit of work in a single pull request.
  • Utworzenie i opublikowanie nowego artykułu, co zwykle wymaga bardziej zaawansowanego edytora lokalnego.Creating and publishing a new article, which typically requires a more robust local editor.
  • Dodanie nowych obrazów lub zaktualizowanie obrazów, co zwykle wymaga jednoczesnego utworzenia nowego podkatalogu media, plików obrazów, aktualizacji linków obrazów w artykułach i wyświetlenia podglądu plików markdown w edytorze lokalnym w celu przetestowania renderowania obrazu.Adding new images or updating images, which typically requires simultaneous creation of a new media subdirectory, image files, updates to image links in articles, and previewing markdown files in a local editor to test image rendering.
  • Aktualizowanie artykułu przez wiele dni przed opublikowaniem.Updating an article over a period of days before you publish. Dotyczy to zwykle regularnej integracji innych zmian w gałęzi głównej.In these cases, you typically need to do regular integration of other changes that occur in the master branch. Jest to łatwiejsze w przypadku powłoki Git Bash i edytowania lokalnego.This integration is easier via Git Bash and local editing. Używanie w tym celu interfejsu użytkownika usługi GitHub wiąże się też z ryzykiem utraty zmian podczas oczekiwania na zatwierdzenie zmian.You also run the risk of losing your edits if you do this via the GitHub UI and wait before you commit the changes.
  • Ciągłe aktualizowanie tego samego artykułu po otwarciu żądania ściągnięcia (jeśli zrobienie tego przy użyciu interfejsu użytkownika usługi GitHub stanowi problem).Making continual updates to the same article after a pull request has been opened (unless you are comfortable doing this via the GitHub UI). Interfejs użytkownika usługi GitHub umożliwia utworzenie wielu osobnych żądań ściągnięcia dla tego samego pliku, co może powodować konflikty między żądaniami.Using the GitHub UI has the potential to create multiple outstanding pull requests for the same file, which may conflict with one another.

TerminologiaTerminology

Zanim rozpoczniemy, omówmy niektóre terminy i krótkie nazwy dotyczące systemu Git i serwisu GitHub użyte w tym przepływie pracy.Before you start, let's review some of the Git/GitHub terms and monikers used in this workflow. Nie musisz czytać o nich teraz.Don't worry about understanding them now. Wystarczy wiedzieć, że są tu na ich temat informacje i można odwołać się do tej sekcji, jeśli trzeba będzie zweryfikować jakąś definicję.Just know that you will be learning about them, and you can refer back to this section when you need to verify a definition.

NazwaName OpisDescription
rozwidleniefork Zwykle pojęcie to jest używane w formie rzeczownika i oznacza kopię głównego repozytorium w serwisie GitHub.Normally used as a noun, when referring to a copy of a main GitHub repository. W praktyce rozwidlenie stanowi po prostu kolejne repozytorium.In practice, a fork is just another repository. Jego cechą charakterystyczną jest to, że serwis GitHub zachowuje połączenie z repozytorium głównym/nadrzędnym.But it's special in the sense that GitHub maintains a connection back to the main/parent repository. Pojęcie to jest czasami używane w formie czasownika, np. w komunikacie „You must fork the repository first” („Musisz najpierw utworzyć rozwidlenie repozytorium”).It's sometimes used as a verb, as in "You must fork the repository first."
połączenie zdalneremote Nazwane połączenie z repozytorium zdalnym, np. połączenie zdalne „pierwotne” lub „nadrzędne”.A named connection to a remote repository, such as the "origin" or "upstream" remote. W usłudze Git takie połączenia są nazywane połączeniami zdalnymi, ponieważ służą do odwoływania się do repozytorium hostowanego na innym komputerze.Git refers to this as remote because it is used to reference a repository that's hosted on another computer. W tym przepływie połączenie zdalne jest zawsze połączeniem z repozytorium w serwisie GitHub.In this workflow, a remote is always a GitHub repository.
połączenie pierwotneorigin Nazwa przypisana do połączenia między repozytorium lokalnym a repozytorium, z którego zostało ono sklonowane.The name assigned to the connection between your local repository and the repository from which it was cloned. W tym przepływie połączenie pierwotne stanowi połączenie z rozwidleniem.In this workflow, origin represents the connection to your fork. Czasami służy jako krótka nazwa samego repozytorium origin, jak w przypadku komunikatu „Remember to push your changes to origin” (Pamiętaj, aby przekazać zmiany do repozytorium origin).It's sometimes used as a moniker for the origin repository itself, as in "Remember to push your changes to origin."
połączenie nadrzędneupstream Tak jak połączenie zdalne pierwotne połączenie nadrzędne jest nazwanym połączeniem z innym repozytorium.Like the origin remote, upstream is a named connection to another repository. W tym przepływie pracy połączenie nadrzędne stanowi połączenie między repozytorium lokalnym i repozytorium głównym, z którego zostało utworzone rozwidlenie.In this workflow, upstream represents the connection between your local repository and the main repository, from which your fork was created. Czasami służy jako krótka nazwa samego repozytorium upstream, jak w przypadku komunikatu „Remember to pull the changes from upstream” (Pamiętaj, aby ściągać zmiany z repozytorium upstream).It's sometimes used as a moniker for the upstream repository itself, as in "Remember to pull the changes from upstream."

Przepływ pracyWorkflow

Ważne

Należy wykonać czynności w sekcji Konfiguracja, jeśli jeszcze nie zostały wykonane.If you haven't already, you must complete the steps in the Setup section. Ta sekcja zawiera instrukcje konfigurowania konta w usłudze GitHub, instalowania powłoki Git Bash oraz edytora języka Markdown, tworzenia rozwidlenia oraz konfigurowania repozytorium lokalnego.This section walks you through setting up your GitHub account, installing Git Bash and a Markdown editor, creating a fork, and setting up your local repository. Jeśli nie znasz pojęć dotyczących usług Git i GitHub, takich jak repozytorium lub gałąź, przejrzyj najpierw artykuł Git and GitHub fundamentals (Podstawy usług Git i GitHub).If you are unfamiliar with Git and GitHub concepts such as a repository or branch, please first review Git and GitHub fundamentals.

W tym przepływie pracy zmiany odbywają się w powtarzających się cyklach.In this workflow, changes flow in a repetitive cycle. Zaczynając od lokalnego repozytorium urządzenia, są przesyłane z powrotem do rozwidlenia w serwisie GitHub, do repozytorium głównego serwisu GitHub i znowu z powrotem lokalnie podczas wdrażania zmian innych współautorów.Starting from your device's local repository, they flow back up to your GitHub fork, into the main GitHub repository, and back down locally again as you incorporate changes from other contributors.

Stosowanie przepływu usługi GitHubUse GitHub flow

Jak pamiętamy z artykułu Git and GitHub fundamentals (Podstawy usług Git i GitHub), repozytorium w usłudze Git zawiera gałąź główną oraz dodatkowe gałęzie pracy w toku, które nie zostały zintegrowane z gałęzią główną.Recall from Git and GitHub fundamentals that a Git repository contains a master branch, plus any additional work-in-progress branches that have not been integrated into master. Gdy wprowadzasz zestaw logicznie powiązanych zmian, najlepszym rozwiązaniem jest utworzenie gałęzi roboczej do zarządzania zmianami przy użyciu przepływu pracy.Whenever you introduce a set of logically related changes, it’s a best practice to create a working branch to manage your changes through the workflow. Nazywamy ją tutaj gałęzią roboczą, gdyż jest to przestrzeń robocza do iterowania/aktualizowania zmian, aż będzie je można znowu zintegrować z gałęzią główną.We refer to it here as a working branch because it's a workspace to iterate/refine changes, until they can be integrated back into the master branch.

Wyizolowanie powiązanych zmian do określonej gałęzi umożliwia kontrolowanie i wprowadzanie tych zmian niezależnie oraz przeznaczanie ich na określony czas wydania w cyklu publikowania.Isolating related changes to a specific branch allows you to control and introduce those changes independently, targeting them to a specific release time in the publishing cycle. W praktyce w zależności od rodzaju wykonywanych prac może dojść do tego, że w repozytorium będzie kilka gałęzi roboczych.In reality, depending on the type of work you do, you can easily end up with several working branches in your repository. Praca nad wieloma gałęziami równocześnie nie należy do rzadkości, a wtedy każda z nich reprezentuje inny projekt.It's not uncommon to be working on multiple branches at the same time, each representing a different project.

Porada

Wprowadzanie zmian w gałęzi głównej nie jest dobrym rozwiązaniem.Making your changes in the master branch is not a good practice. Wyobraźmy sobie, że użyliśmy gałęzi głównej, aby wprowadzić serię zmian w celu wydania funkcji w określonym momencie.Imagine that you use the master branch to introduce a set of changes for a timed feature release. Dokonaliśmy zmian i czekamy na ich wydanie.You finish the changes and are waiting to release them. Tymczasem pojawiło się nagłe żądanie wprowadzenia poprawki, więc wprowadziliśmy zmianę do pliku w gałęzi głównej, po czym opublikowaliśmy zmianę.Then in the interim, you have an urgent request to fix something, so you make the change to a file in the master branch and then publish the change. W tym przykładzie opublikowaliśmy nieumyślnie zarówno poprawkę, jak i zmiany zachowane do wydania określonego dnia.In this example, you inadvertently publish both the fix and the changes that you were holding for release on a specific date.

Teraz utworzymy nową gałąź roboczą w lokalnym repozytorium, aby przechwycić proponowane zmiany.Now let's create a new working branch in your local repository, to capture your proposed changes. Jeśli skonfigurowano powłokę Git Bash (zobacz Instalowanie narzędzi do tworzenia zawartości), możesz utworzyć nową gałąź i wyewidencjonować ją przy użyciu jednego polecenia z poziomu sklonowanego repozytorium:If you've setup Git Bash (see Install content authoring tools), you can create a new branch and "checkout" that branch with one command from within your cloned repository:

git checkout -b "branchname"

Każdy klient usługi Git jest inny, dlatego należy korzystać z pomocy dotyczącej preferowanego klienta.Each git client is different, so consult the help for your preferred client. Omówienie procesu można zobaczyć w przewodniku usługi GitHub w artykule GitHub flow (Przepływ usługi GitHub).You can see an overview of the process in the GitHub Guide on GitHub flow.

Wprowadzanie zmianMaking your changes

Teraz, gdy masz kopię („klona”) repozytorium Microsoft i utworzoną gałąź, możesz wprowadzić dowolne zmiany, które według Ciebie będą korzystne dla społeczności, korzystając z dowolnego edytora tekstu lub języka Markdown, zgodnie z informacjami na stronie Instalowanie narzędzi do tworzenia zawartości.Now that you have a copy ("clone") of the Microsoft repository and you've created a branch, you're now free to make whatever changes you think would benefit the community using any text or Markdown editor, as outlined on the Install content authoring tools page. Zmiany możesz zapisywać lokalnie. Nie ma konieczności przesyłania ich do firmy Microsoft, dopóki nie będą całkowicie gotowe.You can save your changes locally without needing to submit them to Microsoft until you're ready.

Zapisywanie zmian w repozytoriumSaving changes to your repository

Przed wysłaniem zmian do autora musisz najpierw zapisać je w swoim repozytorium GitHub.Before sending your changes to the author, you must first save them to your Github repository. W każdym narzędziu odbywa się to inaczej, ale jeśli używasz wiersza polecenia Git Bash, wystarczy wykonać kilka prostych kroków.Again, while all tools are different, if you're using the Git Bash command line, this can be done in just a few easy steps.

Najpierw z poziomu repozytorium musisz przygotować wszystkie zmiany do zatwierdzenia.First, from within the repository, you need to stage all of your changes to be commmited. W tym celu należy wykonać następujące polecenie:This can be done by executing:

git add --all

Następnie musisz zatwierdzić zapisane zmiany w lokalnym repozytorium.Next, you need to commit your saved changes to your local repository. To zadanie można wykonać w powłoce Git Bash, wykonując polecenie:This can be done in Git Bash by running:

git commit -m "Short Description of Changes Made"

Na koniec, ponieważ ta gałąź została utworzona na komputerze lokalnym, musisz wysłać informacje o niej do rozwidlenia na koncie GitHub.com.Finally, since you created this branch on your local computer, you need to let the fork in your GitHub.com account know about it. Jeśli używasz powłoki Git Bash, możesz to zrobić, wykonując polecenie:If you're using Git Bash, this can be done by running:

git push --set-upstream origin <branchname>

Gotowe!You've done it! Kod znajduje się teraz w repozytorium GitHub i można dla niego utworzyć żądanie ściągnięcia.Your code is now up in your GitHub repository and ready for you to create a pull request.

Porada

Chociaż po wypchnięciu zmiany staną się widoczne na osobistym koncie usługi GitHub, nie ma reguły nakazującej natychmiastowe przesłanie żądania ściągnięcia.Even though your changes become visible in your personal GitHub account when you push them, there is no rule that you need to submit a pull request immediately. Jeśli chcesz przerwać pracę i wrócić do niej później, aby wprowadzić drobne zmiany, możesz to zrobić.If you want to come stop and return at a later time to make additional tweaks, that's OK!

Chcesz poprawić przesłaną zawartość?Need to fix something you submitted? Żaden problem.No problem! Po prostu wprowadź zmiany w tej samej gałęzi, a następnie jeszcze raz zatwierdź je i wypchnij (w przypadku kolejnych operacji wypychania w ramach tej samej gałęzi nie trzeba ustawiać serwera połączenia nadrzędnego).Just make your changes in the same branch and then commit and push again (no need to set the upstream server on subsequent pushes of the same branch).

Wprowadzanie następnej zmianyMaking your next change

Chcesz wprowadzić inne zmiany, które nie są powiązane z tymi?Got more changes you need to make unrelated to this one? Przełącz się z powrotem do gałęzi głównej, ściągnij z repozytorium nadrzędnego, aby upewnić się, że rozwidlenie jest aktualne, i wyewidencjonuj nową gałąź.Switch back to the master branch, pull from the upstream repository to make sure that your fork is up to date, and check out a new branch. Uruchom następujące polecenia w aplikacji Git Bash:Run the following commands in Git Bash:

git checkout master
git pull upstream master
git checkout -b "branchname"

Teraz jesteś w nowej gałęzi i na dobrej drodze do zostania biegłym współautorem.You're now back in a new branch and you're well on your way to being a master contributer.

Przetwarzanie żądania ściągnięciaPull request processing

W poprzedniej sekcji omówiono proces przesyłania proponowanych zmian przez umieszczenie ich w pakiecie w nowym żądaniu ściągnięcia dodawanym do kolejki żądań ściągnięcia repozytorium docelowego.The previous section walked you through the process of submitting proposed changes, by bundling them in a new pull request (PR) that is added to the destination repository's PR queue. Żądanie ściągnięcia włącza model współpracy usługi GitHub przez zażądanie ściągnięcia zmian z gałęzi roboczej i scalenia ich z inną gałęzią.A pull request enables GitHub's collaboration model, by asking for the changes from your working branch to be pulled and merged into another branch. W większości przypadków ta inna gałąź to gałąź domyślna lub gałąź główna w repozytorium głównym.In most cases, that other branch is the default/master branch in the main repository.

WeryfikacjaValidation

Zanim żądanie ściągnięcia będzie mogło zostać scalone z gałęzią docelową, może być konieczne jego przejście przez jeden lub więcej procesów weryfikowania żądań ściągnięcia.Before your pull request can be merged into its destination branch, it might be required to pass through one or more PR validation processes. Procesy weryfikowania mogą się różnić zależnie od zakresu proponowanych zmian i reguły repozytorium docelowego.Validation processes can vary depending on the scope of proposed changes and the rules of the destination repository. Po przesłaniu żądania ściągnięcia mogą zostać przeprowadzone następujące testy:After your pull request is submitted, you can expect one or more of the following to happen:

  • Możliwość scalania: najpierw przeprowadzany jest test linii bazowej dotyczący możliwości scalania w usłudze GitHub w celu sprawdzenia, czy proponowane zmiany w gałęzi nie powodują konfliktu z gałęzią docelową.Mergeability: A baseline GitHub mergeability test occurs first, to verify whether the proposed changes in your branch are not in conflict with the destination branch. Jeśli żądanie ściągnięcia nie przejdzie pomyślnie tego testu, będzie konieczne usunięcie zawartości powodującej konflikt scalania, aby można było kontynuować przetwarzanie.If the pull request indicates that this test failed, you must reconcile the content that is causing the merge conflict before processing can continue.
  • Umowa licencyjna udziału: jeśli współtworzysz zawartość w repozytorium publicznym i nie jesteś pracownikiem firmy Microsoft, przy pierwszej próbie przesłania żądania ściągnięcia do tego repozytorium może być konieczne wypełnienie krótkiej umowy licencyjnej udziału.CLA: If you are contributing to a public repository and are not a Microsoft employee, depending on the magnitude of the proposed changes, you might be asked to complete a short Contribution License Agreement (CLA) the first time you submit a pull request to that repository. Żądanie ściągnięcia zostanie przetworzone po wykonaniu kroku z umową licencyjną udziału.After the CLA step is cleared, your pull request is processed.
  • Tworzenie etykiet: do żądania ściągnięcia są automatycznie stosowane etykiety, które wskazują stan żądania przekazywanego w ramach przepływu pracy weryfikacji.Labeling: Labels are automatically applied to your pull request, to indicate the state of your pull request as it passes through the validation workflow. Na przykład do nowych żądań ściągnięcia może być automatycznie stosowana etykieta wskazująca brak możliwości scalenia z powodu nieukończonego procesu weryfikacji, przeglądu i akceptacji.For instance, new pull requests might automatically receive the "do-not-merge" label, indicating that the pull request has not yet completed the validation, review, and sign-off steps.
  • Weryfikacja i kompilacja: zautomatyzowane kontrole sprawdzają, czy zmiany przeszły testy poprawności.Validation and build: Automated checks verify whether your changes pass validation tests. Testy weryfikacyjne mogą zwracać ostrzeżenia lub błędy, które wymagają wprowadzenia zmian w co najmniej jednym pliku w żądaniu ściągnięcia przed scaleniem.The validation tests might yield warnings or errors, requiring you to make changes to one or more files in your pull request before it can be merged. Wyniki testów weryfikacyjnych są dodawane do żądania ściągnięcia jako komentarz, który możesz przejrzeć, i mogą zostać wysłane pocztą e-mail.The validation test results are added as a comment in your pull request for your review, and they might be sent to you in e-mail.
  • Przygotowywanie: strony artykułów, których dotyczą zmiany, mogą zostać automatycznie wdrożone w środowisku przygotowawczym na potrzeby przeglądu po pomyślnej weryfikacji i kompilacji.Staging: The article pages affected by your changes are automatically deployed to a staging environment for review upon successful validation and build. Adresy URL podglądu są udostępniane w komentarzu do żądania ściągnięcia.Preview URLs appear in a PR comment.
  • Automatyczne scalanie: żądanie ściągnięcia może zostać automatycznie scalone, jeśli pomyślnie przejdzie testy poprawności i spełni określone kryteria.Auto-merge: The pull request might be automatically merged, if it passes validation testing and certain criteria. W takim przypadku nie trzeba podejmować żadnych dalszych akcji.In this case, you don't need to take any further action.

Przegląd i akceptacjaReview and sign-off

Po zakończeniu całego procesu przetwarzania żądania ściągnięcia przejrzyj wyniki (komentarze do żądania, adresy URL podglądu itp.), aby ustalić, czy przed jego zaakceptowaniem lub scaleniem należy wprowadzić dodatkowe zmiany w jego plikach.After all PR processing is completed, you should review the results (PR comments, preview URLs, etc.) to determine if additional changes to its files are required before you sign off for merging. Jeśli żądanie ściągnięcia zostało przejrzane przez recenzenta, mógł on dodać komentarze z informacją o problemach do rozwiązania lub pytaniami wymagającymi odpowiedzi przed scaleniem.If a PR reviewer has reviewed your pull request, they can also provide feedback via comments if there are outstanding issues/questions to be resolved prior to merge.

Automatyzacja komentarza umożliwia użytkownikom mającym poziom uprawnień do odczytu (użytkownikom, którzy nie mają uprawnień do zapisu w repozytorium) wykonanie akcji na poziomie uprawnień do zapisu dzięki przypisaniu odpowiedniej etykiety do żądania ściągnięcia.Comment automation enables read-level users (users who don't have write permissions in a repo) to perform a write-level action, by assigning the appropriate label to a pull request. Jeśli pracujesz w repozytorium, w którym zaimplementowano automatyzację komentarza, użyj komentarzy z hasztagami wymienionych w poniższej tabeli, aby przypisać etykiety, etykiety zmiany lub zamknąć żądanie ściągnięcia.If you are working in a repository where comment automation has been implemented, use the hashtag comments listed in the following table to assign labels, change labels, or close a pull request. Pracownicy firmy Microsoft również zostaną powiadomieni pocztą e-mail o sprawdzeniu i zaakceptowaniu żądań ściągnięcia publicznego repozytorium zawsze, gdy dla artykułów Twojego autorstwa zostaną zaproponowane zmiany.Microsoft employees will also be notified via e-mail for review and sign-off of public repository PRs, whenever changes are proposed to articles for which you are the author.

Komentarz z hasztagiemHashtag comment Jaką pełni funkcjęWhat it does Dostępność repozytoriumRepo availability
#sign-off Gdy autor artykułu wpisze komentarz #sign-off w strumieniu komentarza, zostanie przypisana etykieta gotowe do scalenia.When the author of an article types the #sign-off comment in the comment stream, the ready-to-merge label is assigned. Ta etykieta umożliwia recenzentom w repozytorium dowiedzenie się, kiedy żądanie ściągnięcia jest gotowe do przeglądu/scalenia.This label lets the reviewers in the repo know when a pull request is ready for review/merge.

Jeśli współautor, który nie jest wymienionym autorem, spróbuje zaakceptować publiczne żądanie ściągnięcia za pomocą komentarza #sign-off, zostanie napisany komunikat do żądania ściągnięcia wskazujący, że tylko autor może przypisać etykietę.If a contributor who is not the listed author tries to sign off on a public repo pull request by using the #sign-off comment, a message is written to the pull request indicating that only the author can assign the label.
Publiczne i prywatnePublic and private
#hold-off Autorzy mogą wpisać #hold-off w komentarzu do żądania ściągnięcia, aby usunąć etykietę gotowe do scalenia — w przypadku zmiany zdania lub popełnienia błędu.Authors can type #hold-off in a PR comment to remove the ready-to-merge label--in case they change their mind or make a mistake. W prywatnym repozytorium powoduje to przypisanie etykiety nie scalaj.In the private repo, this assigns the do-not-merge label. Publiczne i prywatnePublic and private
#please-close Autorzy mogą wpisać #please-close w strumieniu komentarza, aby zamknąć żądanie ściągnięcia, jeśli postanowią nie scalać zmian.Authors can type #please-close in the comment stream to close the pull request if they decide not to have the changes merged. PublicznePublic

Po rozwiązaniu problemów i zaakceptowaniu żądania ściągnięcia zmiany są scalane z powrotem z gałęzią nadrzędną, a żądanie ściągnięcia jest zamykane.When the pull request is issue-free and signed off, your changes are merged back into the parent branch and the pull request is closed.

PublikowaniePublishing

Żądanie ściągnięcia musi zostać scalone przez recenzenta żądania, aby zmiany mogły zostać uwzględnione w następnym zaplanowanym przebiegu publikowania.Remember, your pull request has to be merged by a PR reviewer before the changes can be included in the next scheduled publishing run. Żądania ściągnięcia są zwykle przeglądane/scalane w takiej kolejności, w jakiej zostały przesłane.Pull requests are normally reviewed/merged in the order of submission. Jeśli żądanie ściągnięcia wymaga scalenia w ramach określonego przebiegu publikowania, skontaktuj się wcześniej z recenzentem żądania, aby upewnić się, że scalanie zostanie przeprowadzone przed publikowaniem.If your pull request requires merging for a specific publishing run, you will need to work with your PR reviewer ahead of time to ensure that merging happens prior to publishing.

Zatwierdzone i scalone zmiany są pobierane w ramach procesu publikowania w witrynie docs.microsoft.com.After your contributions are approved and merged, the docs.microsoft.com publishing process picks them up. Czas publikowania różni się w zależności od zespołu zarządzającego repozytorium, w którym wprowadzasz zmiany.Depending on the team that manages the repository you are contributing to, publishing times can vary. Artykuły opublikowane na poniższych stronach są zwykle wdrażane od poniedziałku do piątku ok. 10:30 i 15:30 czasu pacyficznego:Articles published under the following paths are normally deployed at approximately 10:30 AM and 3:30 PM Pacific Time, Monday-Friday:

Artykuły mogą zostać wyświetlone online do 45 minut po opublikowaniu.It can take up to 45 minutes for articles to appear online after publishing. Po opublikowaniu artykułu możesz sprawdzić zmiany, używając odpowiedniego adresu URL: https://docs.microsoft.com/<path-to-your-article-without-the-md-extension>.After your article is published, you can verify your changes at the appropriate URL: https://docs.microsoft.com/<path-to-your-article-without-the-md-extension>.

Następne krokiNext steps

Gotowe.That's it! Tworzenie zawartości w witrynie docs.microsoft.com zostało zakończone.You've made a contribution to docs.microsoft.com content!

  • Aby dowiedzieć się więcej o języku Markdown, składni jego rozszerzeń itd., przejdź do artykułu Dokumentacja języka Markdown.To learn more about topics such as Markdown and Markdown extensions syntax, continue to the Markdown reference article.