Skip to content

Latest commit

 

History

History
79 lines (41 loc) · 3.82 KB

git-commands-for-master.md

File metadata and controls

79 lines (41 loc) · 3.82 KB
Raw

Git commands for creating a new article or updating an existing article

Standard process (working from master)

Follow the steps in this article to create a local working branch on your computer so that you can create a new article for the technical documentation section of azure.microsoft.com or update an existing article.

  1. Start Git Bash (or the command-line tool you use for Git).

Note: If you are working in the public repository, change azure-content-pr to azure-content in all the commands.

  1. Change to azure-content-pr:

     cd azure-content-pr

  2. Check out the master branch:

     git checkout master

  3. Create a fresh local working branch derived from the master branch:

     git pull upstream master:<working branch>

  4. Move into the new working branch:

     git checkout <working branch>

  5. Let your fork know you created the local working branch:

     git push origin <working branch>

  6. Create your new article or make changes to an existing article. Use Windows Explorer to open and create new markdown files, and use Atom (http://atom.io) as your markdown editor. After you created or modified your article and images, go to the next step.

  7. Add and commit the changes you made:

     git add .
 git commit –m "<comment>"

    Or, to add only the specific files you modified:

     git add <file path>
 git commit –m "<comment>"

  8. Update your local working branch with changes from upstream:

     git pull upstream master

  9. Push the changes to your fork on GitHub:

    git push origin <working branch>

  10. When you are ready to submit your content to the upstream master branch for staging, validation, and/or publishing, in the GitHub UI, create a pull request from your fork to the master branch.

  11. If you are an employee working in the private repository, the changes you submit are automatically staged and a staging link is written to the pull request. Please review your staged content and sign off in the pull request comments by adding the #sign-off comment. This indicates the changes are ready to be pushed live. If you don't want the pull request to be accepted - if you are just staging the changes - add the #hold-off note to the pull request.

  12. The pull request acceptor reviews your pull request, provides feedback, and/or accepts your pull request.

  13. Optionally verify your published article or changes at

http://azure.microsoft.com/documentation/articles/*name-of-your-article-without-the-MD-extension*

Notes:

  • At this time, technical articles are published once daily around 10 AM Pacific Standard Time (PST), Monday-Friday. Remember, your pull request has to be accepted before changes are included in the next scheduled publishing run.
  • If you are an employee working in the private repository, all pull requests are subject to validation rules that need to be addressed before the pull request can be accepted.

Working with release branches

When you are working with a release branch, the best way to create a local working branch from the release branch is to use this command syntax:

git checkout upstream/<upstream branch name> -b <local working branch name>

This creates the local branch directly from the upstream branch, avoiding any local merging.