Pracovný postup prispievania do služby GitHub pre významné alebo dlhodobé zmenyGitHub contribution workflow for major or long-running changes

Dôležité

Všetky odkladacie priestory, ktoré publikujú na lokalite docs.microsoft.com, prijali pravidlá správania Microsoft Open Source Code of Conduct alebo .NET Foundation Code of Conduct.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. Ďalšie informácie nájdete v téme Najčastejšie otázky pre pravidlá správania.For more information, see the Code of Conduct FAQ. Ak máte akékoľvek otázky alebo komentáre, obráťte sa na adresu opencode@microsoft.com alebo conduct@dotnetfoundation.org.Or contact opencode@microsoft.com, or conduct@dotnetfoundation.org with any questions or comments.

Drobné opravy alebo objasnenia k dokumentácii a príklady kódov vo verejných odkladacích priestoroch sú uvedené v Podmienkach používania lokality 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. Nové alebo významné zmeny budú mať za následok vygenerovanie komentára v žiadosti o prijatie zmien. Ak nie ste zamestnancom spoločnosti Microsoft, zobrazí sa žiadosť o odoslanie online Licenčnej zmluvy o prispievaní (CLA).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. Pred zlúčením žiadosti o prijatie zmien budete musieť vyplniť online formulár.You will need to complete the online form before your pull request can be merged.

PrehľadOverview

Tento pracovný postup je vhodný pre prispievateľa, ktorý potrebuje vykonať významnú zmenu alebo bude častým prispievateľom do odkladacieho priestoru.This workflow is suitable for a contributor who needs to make a major change or will be a frequent contributor to a repository. Častí prispievatelia majú zvyčajne prebiehajúce (dlhodobé) zmeny, ktoré prechádzajú viacerými cyklami typu vytvorenie/overenie/pracovná verzia alebo trvajú viac dní predtým, ako sa žiadosť o prijatie zmien dokončí a zlúči.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.

Príklady týchto druhov príspevkov zahŕňajú:Examples of these types of contributions include:

  • Pridanie veľkého príspevku.Making a large contribution. Môžete napríklad robiť veľké príspevky (dodatky, zmeny alebo odstránenia), ktoré sa týkajú viacerých článkov a je potrebné, aby boli potvrdené a testované ako jedna jednotka práce v jednej žiadosti o prijatie zmien.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.
  • Vytvorenie a publikovanie nového článku, ktoré zvyčajne vyžaduje robustnejší lokálny editor.Creating and publishing a new article, which typically requires a more robust local editor.
  • Pridávanie nových obrázkov alebo aktualizácia obrázkov, ktoré zvyčajne vyžaduje súčasné vytvorenie nového media podadresára, obrázkových súborov, aktualizácií prepojení na obrázky v článkoch a ukážky súborov s jazykom Markdown v lokálnom editore na testovanie vykresľovanie obrázka.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.
  • Aktualizácia článku počas niekoľkých dní pred publikovaním.Updating an article over a period of days before you publish. V týchto prípadoch je zvyčajne potrebné robiť pravidelnú integráciu iných zmien, ktoré sa vyskytujú v hlavej vetve.In these cases, you typically need to do regular integration of other changes that occur in the master branch. Táto integrácia je jednoduchšia cez Git Bash a lokálne úpravy.This integration is easier via Git Bash and local editing. Hrozí aj strata úprav, ak to robíte cez používateľské rozhranie služby GitHub a pred odoslaním zmien čakáte.You also run the risk of losing your edits if you do this via the GitHub UI and wait before you commit the changes.
  • Pridávanie neustálych aktualizácií do toho istého článku po otvorení žiadosti o prijatie zmien (pokiaľ vám neprekáža robiť to cez používateľské rozhranie služby GitHub).Making continual updates to the same article after a pull request has been opened (unless you are comfortable doing this via the GitHub UI). Používanie používateľského rozhrania služby GitHub môže vytvoriť viaceré nevyriešené žiadosti o prijatie zmien pre rovnaký súbor, ktoré môžu byť navzájom v rozpore.Using the GitHub UI has the potential to create multiple outstanding pull requests for the same file, which may conflict with one another.

TerminológiaTerminology

Skôr než začnete, pozrime sa na niektoré pojmy a prezývky v službách Git/GitHub, ktoré sa používajú v tomto pracovnom postupe.Before you start, let's review some of the Git/GitHub terms and monikers used in this workflow. Nerobte si starosti s tým, aby ste ich teraz pochopili.Don't worry about understanding them now. Stačí, keď viete, že sa o nich niečo naučíte, a neskôr, keď si budete potrebovať overiť ich definíciu, sa budete môcť k tejto sekcii vrátiť.Just know that you will be learning about them, and you can refer back to this section when you need to verify a definition.

NázovName DescriptionDescription
vetvafork Bežne sa používa ako podstatné meno, keď sa odkazuje na kópiu hlavného odkladacieho priestoru v službe GitHub.Normally used as a noun, when referring to a copy of a main GitHub repository. V praxi je vetva len ďalší odkladací priestor.In practice, a fork is just another repository. Je však jedinečný v tom, že GitHub udržiava spojenie smerom späť do hlavného/nadradeného odkladacieho priestoru.But it's special in the sense that GitHub maintains a connection back to the main/parent repository. Niekedy sa používa ako sloveso, ako napríklad „Odkladací priestor musíte najskôr vetviť.“It's sometimes used as a verb, as in "You must fork the repository first."
remoteremote Pomenované pripojenie na vzdialený odkladací priestor, ako je napríklad vzdialený „origin“ alebo „upstream“.A named connection to a remote repository, such as the "origin" or "upstream" remote. Git naň odkazuje ako na vzdialené, pretože sa používa na odkazovanie na odkladací priestor, ktorý je umiestnený v inom počítači.Git refers to this as remote because it is used to reference a repository that's hosted on another computer. V tomto pracovnom postupe je vzdialené úložisko vždy odkladací priestor v službe GitHub.In this workflow, a remote is always a GitHub repository.
originorigin Názov priradený spojeniu medzi vaším lokálnym odkladacím priestorom a odkladacím priestorom, z ktorého bol klonovaný.The name assigned to the connection between your local repository and the repository from which it was cloned. V tomto pracovnom postupe origin predstavuje spojenie na vašu vetvu.In this workflow, origin represents the connection to your fork. Niekedy sa používa ako prezývka pre samotný pôvodný odkladací priestor, ako napríklad v hlásení „Nezabudnite zapísať svoje zmeny do pôvodného odkladacieho priestoru.“It's sometimes used as a moniker for the origin repository itself, as in "Remember to push your changes to origin."
upstreamupstream Podobne ako vzdialený origin aj upstream je pomenované pripojenie do iného odkladacieho priestoru.Like the origin remote, upstream is a named connection to another repository. V tomto pracovnom postupe upstream predstavuje spojenie medzi vaším lokálnym odkladacím priestorom a hlavným odkladacím priestorom, z ktorého bola vytvorená vaša vetva.In this workflow, upstream represents the connection between your local repository and the main repository, from which your fork was created. Niekedy sa používa ako prezývka pre samotný upstreamový odkladací priestor, ako napríklad v hlásení „Nezabudnite vytiahnuť zmeny z upstreamu.“It's sometimes used as a moniker for the upstream repository itself, as in "Remember to pull the changes from upstream."

Pracovný postupWorkflow

Dôležité

Ak ste tak ešte neurobili, musíte vykonať kroky v sekcii Nastavenie.If you haven't already, you must complete the steps in the Setup section. Táto sekcia vás prevedie cez nastavenie konta GitHub, inštaláciu Git Bash a editora jazyka Markdown, vytváranie vetvy a nastavenie vášho lokálneho odkladacieho priestoru.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. Ak nie ste oboznámení s konceptami Git a GitHub, ako je odkladací priestor alebo vetva, pozrite si najskôr Základy služby Git a GitHub.If you are unfamiliar with Git and GitHub concepts such as a repository or branch, please first review Git and GitHub fundamentals.

V tomto pracovnom postupe zmeny prebiehajú v opakujúcom cykle.In this workflow, changes flow in a repetitive cycle. Začínajú z miestneho ukladacieho priestoru vášho zariadenia, prúdia späť do vašej vetvy v službe GitHub, do hlavného odkladacieho priestoru v službe GitHub a späť lokálne, keď zapracúvate zmeny od iných prispievateľov.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.

Používanie postupu GitHubUse GitHub flow

Zo základov služby Git a GitHub si spomeňte, že odkladací priestor v službe Git obsahuje hlavnú vetvu, plus akékoľvek ďalšie vetvy prebiehajúcej práce, ktoré neboli začlenené do hlavnej vetvy.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. Vždy, keď zavediete množinu logicky súvisiacich zmien, najlepšie je vytvoriť pracovnú vetvu a spravovať zmeny cez pracovný postup.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. V tomto článku to nazývame ako pracovná vetva, pretože je to pracovný priestor na opakovanie/úpravu zmien, kým ich nebude možné integrovať späť do hlavej vetvy.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.

Izolovanie súvisiacich zmien do určitej vetvy umožňuje ovládať a zavádzať tieto zmeny nezávisle a cieliť ich na špecifické časy vydania v publikačnom cykle.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. V skutočnosti, v závislosti od typu práce, ktorú robíte, môžete ľahko skončiť vo svojom odkladacom priestore s niekoľkými pracovnými vetvami.In reality, depending on the type of work you do, you can easily end up with several working branches in your repository. Nie je nezvyčajné pracovať na viacerých vetvách naraz, pričom každá predstavuje iný projekt.It's not uncommon to be working on multiple branches at the same time, each representing a different project.

Tip

Vykonávanie zmien v hlavej vetve nie je dobrým zvykom.Making your changes in the master branch is not a good practice. Predstavte si, že používate hlavnú vetvu na zavedenie množiny zmien pre načasované uvoľnenie funkcie.Imagine that you use the master branch to introduce a set of changes for a timed feature release. Dokončíte zmeny a čakáte na ich uvoľnenie.You finish the changes and are waiting to release them. Potom sa medzitým objaví naliehavá žiadosť niečo opraviť, takže vykonáte zmenu v súbore v hlavej vetve a potom publikujete zmeny.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. V tomto príklade nevedomky publikujete opravu a aj zmeny, ktoré ste zadržiavali na účely ich uvoľnenia ku konkrétnemu dátumu.In this example, you inadvertently publish both the fix and the changes that you were holding for release on a specific date.

Teraz vytvorme novú pracovnú vetvu v lokálnom odkladacom priestore na zaznamenanie navrhovaných zmien.Now let's create a new working branch in your local repository, to capture your proposed changes. Ak ste nastavili Git Bash (pozrite si tému Inštalácia nástrojov na vytváranie obsahu), môžete vytvoriť novú vetvu a „preveriť“ túto vetvu s jedným príkazom v rámci vášho klonovaného odkladacieho priestoru: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ždý klient služby git je iný, tak si pozrite pomocníka pre svojho preferovaného klienta.Each git client is different, so consult the help for your preferred client. Prehľad procesu nájdete v Príručke pre službu GitHub v postupe GitHub.You can see an overview of the process in the GitHub Guide on GitHub flow.

Vykonanie zmienMaking your changes

Teraz, keď máte kópiu („klon“) odkladacieho priestoru spoločnosti Microsoft a vytvorili ste vetvu, teraz máte možnosť vykonávať akékoľvek zmeny, ktoré sú podľa vás v prospech komunity, pomocou ľubovoľného textového editora alebo editora jazyka Markdown, ako je to uvedené na stránke Inštalácia nástrojov na vytváranie obsahu.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. Zmeny môžete uložiť lokálne bez toho, aby ste ich museli odoslať do spoločnosti Microsoft, kým nebudete pripravení.You can save your changes locally without needing to submit them to Microsoft until you're ready.

Uloženie zmien do odkladacieho priestoruSaving changes to your repository

Pred odoslaním zmien autorovi ich musíte najprv uložiť do svojho odkladacieho priestoru Github.Before sending your changes to the author, you must first save them to your Github repository. Opäť platí, že aj keď sa všetky nástroje líšia, ak používate príkazový riadok Git Bash, dá sa to urobiť len v niekoľkých jednoduchých krokoch.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.

Najskôr musíte v rámci odkladacieho priestoru nastaviť všetky svoje zmeny, ktoré sa majú potvrdiť.First, from within the repository, you need to stage all of your changes to be commmited. Dá sa to vykonať spustením príkazu:This can be done by executing:

git add --all

Potom je potrebné potvrdiť svoje uložené zmeny do lokálneho odkladacieho priestoru.Next, you need to commit your saved changes to your local repository. Je to možné v Git Bash spustením príkazu:This can be done in Git Bash by running:

git commit -m "Short Description of Changes Made"

Napokon, keďže ste túto vetvu vytvorili v lokálnom počítači, potrebujete o tom informovať aj vetvu vo svojom konte 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. Ak používate Git Bash, je to možné urobiť spustením príkazu:If you're using Git Bash, this can be done by running:

git push --set-upstream origin <branchname>

Urobili ste to!You've done it! Váš kód je teraz vo vašom odkladacom priestore GitHub a je pripravený na vytvorenie žiadosti o prijatie zmien.Your code is now up in your GitHub repository and ready for you to create a pull request.

Tip

Napriek tomu, že vaše zmeny sa zobrazia vo vašom osobnom konte GitHub, keď ich prijmete, neexistuje žiadne pravidlo, že je potrebné odoslať žiadosť o prijatie zmien okamžite.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. Ak chcete skončiť a vrátiť sa neskôr, aby ste mohli vykonať ďalšie vylepšenia, je to OK!If you want to come stop and return at a later time to make additional tweaks, that's OK!

Potrebujete opraviť niečo, čo ste odoslali?Need to fix something you submitted? Žiaden problém!No problem! Stačí vykonať zmeny v tej istej vetve a potom ich potvrdiť a prijať znova (nie je potrebné nastaviť následný server pri následných prijatiach zmien v tej istej vetve).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).

Máte viac zmien, ktoré potrebujete nastaviť ako nesúvisiace s touto?Got more changes you need to make unrelated to this one? Prepnite sa späť na hlavnú vetvu a preverte ďalšiu novú vetvu pomocou Git Bash, je to jednoduché:Switch back to the master branch and checkout another fresh branch, Using Git Bash, this is as easy as:

git checkout master
git checkout -b "branchname"

Teraz ste späť v novej vetve a ste na dobrej ceste stať sa hlavným prispievateľom.You're now back in a new branch and you're well on your way to being a master contributer.

Spracovanie žiadosti o prijatie zmienPull request processing

V predchádzajúcej časti sme prešli cez proces odosielania navrhovaných zmien ich zlúčením do novej žiadosti o prijatie zmien (PR), ktorá sa pridá do PR frontu cieľového odkladacieho priestoru.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. Žiadosť o prijatie zmien umožňuje fungovanie modelu spolupráce v službe GitHub tým, že požiada, aby sa zmeny z vašej pracovnej vetvy vytiahli a zlúčili do inej vetvy.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. Vo väčšine prípadov je táto iná vetva predvolená/hlavná vetva v hlavnom odkladacom priestore.In most cases, that other branch is the default/master branch in the main repository.

OverenieValidation

Predtým, ako sa vaša žiadosť o prijatie zmien bude môcť zlúčiť so svojou cieľovou vetvou, môže sa vyžadovať, aby prešla cez jeden alebo viac overovacích procesov PR.Before your pull request can be merged into its destination branch, it might be required to pass through one or more PR validation processes. Overovacie procesy sa môžu líšiť v závislosti od rozsahu navrhovaných zmien a pravidiel cieľového odkladacieho priestoru.Validation processes can vary depending on the scope of proposed changes and the rules of the destination repository. Po odoslaní vašej žiadosti o prijatie zmien môžete očakávať jednu alebo viaceré z týchto situácií:After your pull request is submitted, you can expect one or more of the following to happen:

  • Zlučiteľnosť: Najskôr sa spustí základný test zlučiteľnosti služby GitHub, ktorý overí, či navrhované zmeny vo vašej vetve nie sú v rozpore s cieľovou vetvou.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. Ak žiadosť o prijatie zmien naznačí, že tento test zlyhal, pred pokračovaním spracovania musíte zosúladiť obsah, ktorý spôsobuje konflikt pri zlučovaní.If the pull request indicates that this test failed, you must reconcile the content that is causing the merge conflict before processing can continue.
  • CLA: Ak prispievate do verejného odkladacieho priestoru a nie ste zamestnancom spoločnosti Microsoft, v závislosti od rozsahu navrhovaných zmien sa môže stať, že budete požiadaní, aby ste pri prvom odoslaní žiadosti o prijatie zmien do daného odkladacieho priestoru vyplnili krátku Licenčnú zmluvu na poskytovanie príspevkov (CLA).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. Po vyriešení kroku so zmluvou CLA sa vaša žiadosť o prijatie zmien spracuje.After the CLA step is cleared, your pull request is processed.
  • Označovanie: Menovky sa automaticky použijú vo vašej žiadosti o prijatie zmien na označenie stavu žiadosti počas jej prechodu pracovným postupom overovania.Labeling: Labels are automatically applied to your pull request, to indicate the state of your pull request as it passes through the validation workflow. Žiadosť o prijatie zmien môže napríklad automaticky dostať menovku „nezlučovať“, čo označuje, že žiadosť o prijatie zmien ešte neukončila kroky overenia, revízie a dokončenia.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.
  • Validácia a vytvorenie: Automatizované kontroly overia, či vaše zmeny prejdú testom overenia.Validation and build: Automated checks verify whether your changes pass validation tests. Testy overenia môžu vygenerovať upozornenia alebo chyby a vyžadovať, aby ste vykonali zmeny v jednom alebo viacerých súboroch vašej žiadosti o prijatie zmien a až potom budú môcť byť zlúčené.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. Výsledky testov overenia sa pridajú ako komentár do vašej žiadosti o prijatie zmien, ktorý si môžete prečítať. Môžu sa tiež odoslať e-mailom.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.
  • Pracovná verzia: Stránky s článkami ovplyvnené vašimi zmenami sa po úspešnom overení a vytvorení automaticky nasadia do prostredia pracovnej verzie, kde ich môžete skontrolovať.Staging: The article pages affected by your changes are automatically deployed to a staging environment for review upon successful validation and build. URL adresy ukážky sa zobrazia v komentári PR.Preview URLs appear in a PR comment.
  • Automatické zlúčenie: Žiadosť o prijatie zmien sa môže automaticky zlúčiť, ak prejde testom overenia a splní určité kritériá.Auto-merge: The pull request might be automatically merged, if it passes validation testing and certain criteria. V tomto prípade nemusíte vykonať žiadnu ďalšiu akciu.In this case, you don't need to take any further action.

Revízia a dokončenieReview and sign-off

Keď sa dokončí spracovanie všetkých PR, je potrebné skontrolovať výsledky (komentáre PR, ukážky adries URL atď.), aby ste zistili, či pred dokončením a zlúčením je potrebné vykonať dodatočné zmeny v príslušných súboroch.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. Ak posudzovateľ PR preskúmal vašu žiadosť o prijatie zmien, môže v prípade, že existujú nejaké nevyriešené problémy alebo otázky, ktoré je treba vyriešiť pred zlúčením, poskytnúť spätnú väzbu prostredníctvom komentárov.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.

Automatizácia komentárov umožňuje používateľom na úrovni čítania (používatelia, ktorí nemajú v odkladacom priestore povolenia na zápis) vykonávať akciu na úrovni zápisu pomocou priradenia vhodnej menovky k žiadosti o prijatie zmien.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. Ak pracujete v odkladacom priestore, kde automatizácia komentárov bola implementovaná, použite komentáre typu hashtag uvedené v nasledujúcej tabuľke a priraďte menovky, zmeňte menovky alebo zavrite žiadosť o prijatie zmien.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. Zamestnanci spoločnosti Microsoft budú tiež upozornení prostredníctvom e-mailu na preskúmanie a dokončenie žiadostí o prijatie zmien vo verejnom odkladacom priestore vždy, keď sú navrhnuté zmeny v článkoch, ktorých ste autorom.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.

Komentár typu hashtagHashtag comment Čo urobíWhat it does Dostupnosť odkladacieho priestoruRepo availability
#sign-off Keď autor článku zadá do streamu komentárov komentár #sign-off, priradí sa označenie pripravené na zlúčenie.When the author of an article types the #sign-off comment in the comment stream, the ready-to-merge label is assigned. Toto označenie umožňuje posudzovateľom v odkladacom priestore zistiť, kedy je žiadosť o prijatie zmien pripravená na kontrolu/zlúčenie.This label lets the reviewers in the repo know when a pull request is ready for review/merge.

Ak sa prispievateľ, ktorý nie je uvedený ako autor, snaží prevziať verejnú žiadosť o prijatie zmien pomocou komentára #sign-off, do žiadosti o prijatie zmien sa zapíše správa oznamujúca, že označenie môže priradiť iba autor.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.
Verejné a súkromnéPublic and private
#hold-off Autori môžu do komentára žiadosti o prijatie zmien zadať komentár #hold-off a odstrániť označenie pripravené na zlúčenie v prípade, že zmenia názor alebo urobia chybu.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. V súkromnom odkladacom priestore sa priradí označenie nezlúčiť.In the private repo, this assigns the do-not-merge label. Verejné a súkromnéPublic and private
#please-close Autori môžu do streamu komentárov zadať komentár #please-close a uzavrieť žiadosť o prijatie zmien, ak sa rozhodnú, aby sa zmeny nezlučovali.Authors can type #please-close in the comment stream to close the pull request if they decide not to have the changes merged. VerejnéPublic

Keď je žiadosť o prijatie zmien bez problémov a je dokončená, vaše zmeny sa zlúčia späť do nadradenej vetvy a žiadosť o prijatie zmien sa uzavrie.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.

PublikovaniePublishing

Nezabudnite, že vaša požiadavka na prijatie zmien musí byť zlúčená recenzentom PR a až potom môžu byť zmeny zahrnuté do ďalšieho plánovaného publikovania.Remember, your pull request has to be merged by a PR reviewer before the changes can be included in the next scheduled publishing run. Žiadosti o prijatie zmien sa obvykle kontrolujú a zlučujú v poradí akom boli odoslané.Pull requests are normally reviewed/merged in the order of submission. Ak vaša žiadosť o prijatie zmien vyžaduje zlúčenie v konkrétnom publikovaní, budete musieť spolupracovať s recenzentom PR vopred, aby ste zabezpečili, že zlúčenie sa vykoná pred publikovaním.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.

Keď sú vaše príspevky schválené a zlúčené, proces publikovania na lokalite docs.microsoft.com si ich prevezme.After your contributions are approved and merged, the docs.microsoft.com publishing process picks them up. Čas publikovania môže byť rôzny v závislosti od tímu, ktorý spravuje odkladací priestor, do ktorého prispievate.Depending on the team that manages the repository you are contributing to, publishing times can vary. Články publikované s nasledovnými cestami sa bežne nasadzujú približne o 10:30 a 15:30 pacifického času od pondelka do piatka:Articles published under the following paths are normally deployed at approximately 10:30 AM and 3:30 PM Pacific Time, Monday-Friday:

Zobrazenie článkov online po publikovaní môže trvať až 45 minút.It can take up to 45 minutes for articles to appear online after publishing. Keď je váš článok zverejnený, môžete si svoje zmeny overiť na príslušnej URL adrese: 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>.

Ďalšie krokyNext steps

To je všetko!That's it! Prispeli ste do obsahu na lokalite docs.microsoft.com!You've made a contribution to docs.microsoft.com content!

  • Ďalšie informácie o témach, ako je napríklad jazyk Markdown a syntax rozšírení jazyka Markdown, nájdete v článku Príručka jazyka Markdown.To learn more about topics such as Markdown and Markdown extensions syntax, continue to the Markdown reference article.