This workflow is suitable for a contributor who needs to make a major change or will be a frequent contributor to a repository. 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.
Examples of these types of contributions include:
- Making a large contribution. 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.
- Creating and publishing a new article, which typically requires a more robust local editor.
- Adding new images or updating images, which typically requires simultaneous creation of a new
mediasubdirectory, image files, updates to image links in articles, and previewing markdown files in a local editor to test image rendering.
- Updating an article over a period of days before you publish. In these cases, you typically need to do regular integration of other changes that occur in the master branch. This integration is easier via Git Bash and local editing. You also run the risk of losing your edits if you do this via the GitHub UI and wait before you commit the changes.
- Making continual updates to the same article after a pull request has been opened (unless you are comfortable doing this via the GitHub UI). Using the GitHub UI has the potential to create multiple outstanding pull requests for the same file, which may conflict with one another.
Before you start, let’s review some of the Git/GitHub terms and monikers used in this workflow. Don’t worry about understanding them now. Just know that you will be learning about them, and you can refer back to this section when you need to verify a definition.
|fork||Normally used as a noun, when referring to a copy of a main GitHub repository. In practice, a fork is just another repository. But it’s special in the sense that GitHub maintains a connection back to the main/parent repository. It’s sometimes used as a verb, as in “You must fork the repository first.”|
|remote||A named connection to a remote repository, such as the “origin” or “upstream” remote. Git refers to these as remotes because they are used to reference a repository that’s hosted on another computer. In this workflow, a remote is always a GitHub repository.|
|origin||The name assigned to the connection between your local repository and the repository from which it was cloned. In this workflow, origin represents the connection to your fork. It’s sometimes used as a moniker for the origin repository itself, as in “Remember to push your changes to origin.”|
|upstream||Like the origin remote, upstream is a named connection to another repository. In this workflow, upstream represents the connection between your local repository and the main repository, from which your fork was created. It’s sometimes used as a moniker for the upstream repository itself, as in “Remember to pull the changes from upstream.”|
If you haven’t already, you must complete the steps in the Setup section. 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. If you are unfamiliar with Git and GitHub concepts such as a repository or branch, please first review Git and GitHub fundamentals.
In this workflow, changes flow in a repetitive cycle. 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.
Use GitHub flow
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. 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. 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.
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. In reality, depending on the type of work you do, you can easily end up with several working branches in your repository. It’s not uncommon to be working on multiple branches at the same time, each representing a different project.
Making your changes in the master branch is not a good practice. Imagine that you use the master branch to introduce a set of changes for a timed feature release. You finish the changes and are waiting to release them. 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. In this example, you inadvertently publish both the fix and the changes that you were holding for release on a specific date.
Now let’s create a new working branch in your local repository, to capture your proposed changes. Each git client is different, so consult the help for your preferred client. You can see an overview of the process in the GitHub Guide on GitHub flow.
Pull request processing
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. 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. In most cases, that other branch is the default/master branch in the main repository.
Before your pull request can be merged into its destination branch, it might be required to pass through one or more PR validation processes. Validation processes can vary depending on the scope of proposed changes and the rules of the destination repository. After your pull request is submitted, you can expect one or more of the following to happen:
- Mergeability: A baseline GitHub mergeability test occurs first, to verify whether the proposed changes in your branch are in conflict with the destination branch. 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: 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. After the CLA step is cleared, your pull request is processed.
- Labeling: Labels are automatically applied to your pull request, to indicate the state of your pull request as it passes through the validation workflow. 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.
- Validation and build: Automated checks verify whether your changes pass validation tests. 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. 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.
- Staging: The article pages affected by your changes are automatically deployed to a staging environment for review upon successful validation and build. Preview URLs appear in a PR comment.
- Auto-merge: The pull request might be automatically merged, if it passes validation testing and certain criteria. In this case, you don’t need to take any further action.
Review and sign-off
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. 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.
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. 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. 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.
|Hashtag comment||What it does||Repo availability|
|#sign-off||When the author of an article types the #sign-off comment in the comment stream, the ready-to-merge label is assigned. This label lets the reviewers in the repo know when a pull request is ready for review/merge.||Public and private|
|#sign-off||If a contributor who is not the listed author tries to sign off on a public 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.||Public|
|#hold-off||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. In the private repo, this assigns the do-not-merge label.||Public and private|
|#please-close||Authors can type #please-close in the comment stream to close the pull request if they decide not to have the changes merged.||Public|
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.
Remember, your pull request has to be merged by a PR reviewer before the changes can be included in the next scheduled publishing run. Pull requests are normally reviewed/merged in the order of submission. 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.
After your contributions are approved and merged, the docs.microsoft.com publishing process picks them up. Depending on the team that manages the repository you are contributing to, publishing times can vary. Articles published under the following paths are normally deployed at approximately 10:30 AM and 3:30 PM Pacific Time, Monday-Friday:
It can take up to 45 minutes for articles to appear online after publishing. After your article is published, you can verify your changes at the appropriate URL:
That’s it! You’ve made a contribution to docs.microsoft.com content!
- To learn more about topics such as Markdown and Markdown extensions syntax, continue to the “Writing essentials” section.