Once your Git flow is set up, you can make changes to the repository.
For returning users - Ensure that you are up to date with the ms-iot repo:
git fetch ms-iot
git reset --hard ms-iot/develop
git push origin develop
Note: This will delete all local changes and push ms-iot to your fork, so be sure this is what you want
- Read contributing guidelines.
- Changes that do not follow the guidelines will be rejected
- Edit, build, test
- From within the content folder start a local server using cmd.exe
`jekyll serve --incremental`
-
If prompted by the firewall, allow Jekyll to serve content
-
Open your web browser and point it to the local server. http://localhost:4000/content/en-US/iot.htm is the default page * Note: you won't see the correct formatting with a local server for certain aspects of the website:
- Header/footer
- Some margins
this is to be expected. We still highly recommend rendering and verifying locally
-
Edit using your favorite text editor. Jekyll will automatically update the content after every save
-
If you are adding a new document, ensure that the files and images are saved in the correct folders
-
Commit changes
-
When ready, add the files you want to to be staged for commit: *
git add [file] -
Once done, commit your changes: *
git commit -m "[descriptive message]"
A pull request (PR) is a request to the ms-iot team to accept your changes. It must first be approved by the team, but once accepted, it will immediately go live.
-
Grab the latest changes from upstream
git fetch ms-iot -
Merge it into your local repository
git merge ms-iot/develop- If you run into conflicts, you will have to hand-merge (you can use your favorite merging tool or even notepad for this)
- After hand-merging, you can continue the merge
git add [fileYouHandMerged]
-
Check your repositories status
git status. You may need to continue the merge to finish
-
Push your changes to your forked repository.
git push origin develop
-
Submit your pull request from your forked repository using the GitHub website
- If it's your first pull request, sign the Contribution License Agreement
- Without completing this step, we unfortunately cannot accept a pull request. You only need to do this once
- Make your new changes, fetch upstream, merge upstream, and push your changes
- If your pull request was never closed, you should not have to submit a new pull request. It should automatically update
When evaluating PRs, the following guidelines must be met:
- Must be auto-mergable.
- You should have done the work so that we can automatically merge your changes with the current state of the repository. Otherwise we will reject your pull-request and wait until you have fixed it
- If, after you make your changes and submit your PR, you find it cannot be automerged, simply update your fork with the latest from our repo and fix the conflicts - that should make it auto-mergable
- Never have duplicate commits
If there is a specific date or time that content needs publishing or if there is a pressing bug fix that needs merging ASAP, please email [email protected].
PRs submitted to our public repo will be evaluated and merged individually, usually within a few days of them being submitted. Assume that once the PR is submitted, that content can go live anytime.
WOD moderators will take care of merging private content to public, usually in the middle of the month. Specific date releases of private content must be communicated to stakeholders ahead of time, and give at least a week lead time to verify all parties are on board and verification can happen.