Merge branch 'main' into 3502-secret-scanning-partner-feedback

.github/workflows/autoupdate-branch.yml

@@ -7,7 +7,7 @@ jobs:
   autoupdate:
     if: github.repository == 'github/docs-internal' || github.repository == 'github/docs'
     name: autoupdate
-    runs-on: ubuntu-18.04
+    runs-on: ubuntu-latest
     steps:
       - uses: docker://chinthakagodawita/autoupdate-action:v1
         env:

.github/workflows/codeql.yml

@@ -2,9 +2,11 @@ name: CodeQL analysis
 
 on:
   push:
-    branches: main
+    branches:
+      - main
   pull_request:
-    branches: main
+    branches:
+      - main
     paths:
       - '**/*.js'
       - '.github/workflows/codeql.yml'

.github/workflows/triage-unallowed-contributions.yml

@@ -104,6 +104,7 @@ jobs:
               body: reviewMessage,
               event: 'REQUEST_CHANGES'
             })
+            exit 1 # prevents further steps from running and fails workflow
       # When the most recent review was CHANGES_REQUESTED and the existing
       # PR no longer contains unallowed changes, dismiss the previous review
       - name: Dismiss pull request review

.github/workflows/workflow-lint.yml

@@ -2,12 +2,12 @@ name: Lint workflows
 
 on:
   workflow_dispatch:
-  push:
-    branches:
-      - main
-  pull_request:
-    branches-ignore:
-      - translations
+  # push:
+  #   branches:
+  #     - main
+  # pull_request:
+  #   branches-ignore:
+  #     - translations
 
 jobs:
   lint:

README.md

@@ -18,7 +18,7 @@ We accept a lot of [different contributions](CONTRIBUTING.md/#types-of-contribut
 
 #### Click **make a contribution** from docs
 
-As you're using the GitHub Docs, you may find something in an article that you'd like to add to, update, or change. Click on **make a contribution** to navigate directly to that article in the codebase, so that you can begin making your contribution.
+As you're using GitHub Docs, you may find something in an article that you'd like to add to, update, or change. Click on **make a contribution** to navigate directly to that article in the codebase, so that you can begin making your contribution.
 
 <img src="./assets/images/contribution_cta.png" width="400">
 

content/README.md

@@ -24,6 +24,7 @@ See the [contributing docs](/CONTRIBUTING.md) for general information about work
   - [Escaping single quotes](#escaping-single-quotes)
 - [Autogenerated mini TOCs](#autogenerated-mini-tocs)
 - [Versioning](#versioning)
+  - [Free-pro-team vs. GitHub.com versioning](#free-pro-team-vs.-github.com-versioning)
 - [Filenames](#filenames)
 - [Whitespace control](#whitespace-control)
 - [Links and image paths](#links-and-image-paths)
@@ -213,6 +214,12 @@ A content file can have **two** types of versioning:
 * Liquid statements in content (**optional**)
     * Conditionally render content depending on the current version being viewed. See [contributing/liquid-helpers](../contributing/liquid-helpers.md) for more info. Note Liquid conditionals can also appear in `data` and `include` files.
 
+### Free-pro-team vs. GitHub.com versioning
+
+As of early 2021, the `free-pro-team@latest` version is **only** supported in content files (in both frontmatter and Liquid versioning) and throughout the docs site backend. It is **not** user facing. A helper function called `lib/remove-fpt-from-path.js` removes the version from URLs. Users now select `GitHub.com` in the Article Versions dropdown instead of `Free, Pro, Team`.
+
+The convenience function allows us to continue supporting a consistent versioning structure under-the-hood while not displaying plan information to users that may be potentially confusing.
+
 ## Filenames
 
 When adding a new article, make sure the filename is a [kebab-cased](https://en.wikipedia.org/wiki/Letter_case#Special_case_styles) version of the title you use in the article's [`title`](#title) frontmatter. This can get tricky when a title has punctuation (such as "GitHub's Billing Plans"). A test will flag any discrepancies between title and filename. To override this requirement for a given article, you can add [`allowTitleToDifferFromFilename`](#allowtitletodifferfromfilename) frontmatter.
@@ -224,7 +231,7 @@ When using Liquid conditionals in lists or tables, you can use [whitespace contr
 Just add a hyphen on either the left, right, or both sides to indicate that there should be no newline on that side. For example, this statement removes a newline on the left side:
 
 ```
-{%- if page.version == 'dotcom' %}
+{%- if currentVersion == 'free-pro-team@latest' %}
 ```
 
 These characters are especially important in [index pages](#index-pages) comprised of list items.
@@ -238,9 +245,9 @@ For example, if you include the following link in a content file:
 ```
 /github/writing-on-github/creating-a-saved-reply
 ```
-When viewed on GitHub.com docs, the link gets rendered with the language code and version:
+When viewed on GitHub.com docs, the link gets rendered with the language code:
 ```
-/en/free-pro-team@latest/github/writing-on-github/creating-a-saved-reply
+/en/github/writing-on-github/creating-a-saved-reply
 ```
 and when viewed on GitHub Enterprise Server docs, the version is included as well:
 ```

content/actions/guides/building-and-testing-net.md

@@ -0,0 +1,248 @@
+---
+title: Building and testing .NET
+intro: You can create a continuous integration (CI) workflow to build and test your .NET project.
+product: '{% data reusables.gated-features.actions %}'
+versions:
+  free-pro-team: '*'
+  enterprise-server: '>=2.22'
+---
+
+### Introduction
+
+This guide shows you how to build, test, and publish a .NET package.
+
+{% data variables.product.prodname_dotcom %}-hosted runners have a tools cache with preinstalled software, which includes the .NET Core SDK. For a full list of up-to-date software and the preinstalled versions of .NET Core SDK, see [software installed on {% data variables.product.prodname_dotcom %}-hosted runners](/actions/reference/specifications-for-github-hosted-runners).
+
+### Prerequisites
+
+You should already be familiar with YAML syntax and how it's used with {% data variables.product.prodname_actions %}. For more information, see "[Workflow syntax for {% data variables.product.prodname_actions %}](/actions/automating-your-workflow-with-github-actions/workflow-syntax-for-github-actions)."
+
+We recommend that you have a basic understanding of the .NET Core SDK. For more information, see [Getting started with .NET](https://dotnet.microsoft.com/learn).
+
+### Starting with the .NET workflow template
+
+{% data variables.product.prodname_dotcom %} provides a .NET workflow template that should work for most .NET projects, and this guide includes examples that show you how to customize this template. For more information, see the [.NET workflow template](https://github.com/actions/setup-dotnet).
+
+To get started quickly, add the template to the `.github/workflows` directory of your repository.
+
+{% raw %}
+```yaml
+name: dotnet package
+
+on: [push]
+
+jobs:
+  build:
+
+    runs-on: ubuntu-latest
+    strategy:
+      matrix:
+        dotnet-version: [ '2.2.103', '3.0', '3.1.x' ]
+
+    steps:
+    - uses: actions/checkout@v2
+    - name: Setup .NET Core SDK ${{ matrix.dotnet }}
+      uses: actions/setup-dotnet@v1.6.0
+      with:
+        dotnet-version: {{ matrix.dotnet-version }}
+    - name: Install dependencies
+      run: dotnet restore
+    - name: Build
+      run: dotnet build --configuration Release --no-restore
+    - name: Test
+      run: dotnet test --no-restore --verbosity normal
+```
+{% endraw %}
+
+### Specifying a .NET version
+
+To use a preinstalled version of the .NET Core SDK on a {% data variables.product.prodname_dotcom %}-hosted runner, use the `setup-dotnet` action. This action finds a specific version of .NET from the tools cache on each runner, and adds the necessary binaries to `PATH`. These changes will persist for the remainder of the job.
+ 
+The `setup-dotnet` action is the recommended way of using .NET with {% data variables.product.prodname_actions %}, because it ensures consistent behavior across different runners and different versions of .NET. If you are using a self-hosted runner, you must install .NET and add it to `PATH`. For more information, see the [`setup-dotnet`](https://github.com/marketplace/actions/setup-dotnet).
+
+#### Using multiple .NET versions
+
+{% raw %}
+```yaml
+name: dotnet package
+
+on: [push]
+
+jobs:
+  build:
+
+    runs-on: ubuntu-latest
+    strategy:
+      matrix:
+        dotnet: [ '2.2.103', '3.0', '3.1.x' ]
+
+    steps:
+    - uses: actions/checkout@v2
+    - name: Setup dotnet ${{ matrix.dotnet-version }}
+      uses: actions/setup-dotnet@v1.6.0
+      with:
+        dotnet-version: ${{ matrix.dotnet-version }}
+    # You can test your matrix by printing the current dotnet version
+    - name: Display dotnet version
+      run: dotnet --version
+```
+{% endraw %}
+
+#### Using a specific .NET version
+
+You can configure your job to use a specific version of .NET, such as `3.1.3`. Alternatively, you can use semantic version syntax to get the latest minor release. This example uses the latest minor release of .NET 3.
+
+{% raw %}
+```yaml
+    - name: Setup .NET 3.x
+      uses: actions/setup-dotnet@v2
+      with:
+        # Semantic version range syntax or exact version of a dotnet version
+        dotnet-version: '3.x' 
+```
+{% endraw %}
+
+### Installing dependencies
+
+{% data variables.product.prodname_dotcom %}-hosted runners have the NuGet package manager installed. You can use the dotnet CLI to install dependencies from the NuGet package registry before building and testing your code. For example, the YAML below installs the `Newtonsoft` package.
+
+{% raw %}
+```yaml
+steps:
+- uses: actions/checkout@v2
+- name: Setup dotnet
+  uses: actions/setup-dotnet@v1.6.0
+  with:
+    dotnet-version: '3.1.x'
+- name: Install dependencies
+  run: dotnet add package Newtonsoft.Json --version 12.0.1
+```
+{% endraw %}
+
+{% if currentVersion == "free-pro-team@latest" %}
+
+#### Caching dependencies
+
+You can cache NuGet dependencies using a unique key, which allows you to restore the dependencies for future workflows with the [`cache`](https://github.com/marketplace/actions/cache) action. For example, the YAML below installs the `Newtonsoft` package.
+
+For more information, see "[Caching dependencies to speed up workflows](/actions/guides/caching-dependencies-to-speed-up-workflows)."
+
+{% raw %}
+```yaml
+steps:
+- uses: actions/checkout@v2
+- name: Setup dotnet
+  uses: actions/setup-dotnet@v1.6.0
+  with:
+    dotnet-version: '3.1.x'
+- uses: actions/cache@v2
+  with:
+    path: ~/.nuget/packages
+    # Look to see if there is a cache hit for the corresponding requirements file
+    key: ${{ runner.os }}-nuget-${{ hashFiles('**/packages.lock.json') }}
+    restore-keys: |
+      ${{ runner.os }}-nuget
+- name: Install dependencies
+  run: dotnet add package Newtonsoft.Json --version 12.0.1
+```
+{% endraw %}
+
+{% note %}
+
+**Note:** Depending on the number of dependencies, it may be faster to use the dependency cache. Projects with many large dependencies should see a performance increase as it cuts down the time required for downloading. Projects with fewer dependencies may not see a significant performance increase and may even see a slight decrease due to how NuGet installs cached dependencies. The performance varies from project to project.
+
+{% endnote %}
+
+{% endif %}
+
+### Building and testing your code
+
+You can use the same commands that you use locally to build and test your code. This example demonstrates how to use `dotnet build` and `dotnet test` in a job:
+
+{% raw %}
+```yaml
+steps:
+- uses: actions/checkout@v2
+- name: Setup dotnet
+  uses: actions/setup-dotnet@v1.6.0
+  with:
+    dotnet-version: '3.1.x'
+- name: Install dependencies
+  run: dotnet restore
+- name: Build
+  run: dotnet build
+- name: Test with the dotnet CLI
+  run: dotnet test
+```
+{% endraw %}
+
+### Packaging workflow data as artifacts
+
+After a workflow completes, you can upload the resulting artifacts for analysis. For example, you may need to save log files, core dumps, test results, or screenshots. The following example demonstrates how you can use the `upload-artifact` action to upload test results.
+
+For more information, see "[Persisting workflow data using artifacts](/github/automating-your-workflow-with-github-actions/persisting-workflow-data-using-artifacts)."
+
+{% raw %}
+```yaml
+name: dotnet package
+
+on: [push]
+
+jobs:
+  build:
+
+    runs-on: ubuntu-latest
+    strategy:
+      matrix:
+        dotnet-version: [ '2.2.103', '3.0', '3.1.x' ]
+
+      steps:
+      - uses: actions/checkout@v2
+      - name: Setup dotnet
+        uses: actions/setup-dotnet@v1.6.0
+        with:
+          dotnet-version: ${{ matrix.dotnet-version }}
+      - name: Install dependencies
+        run: dotnet restore
+      - name: Test with dotnet
+        run: dotnet test --logger trx --results-directory "TestResults-${{ matrix.dotnet-version }}"
+      - name: Upload dotnet test results
+        uses: actions/upload-artifact@v2
+        with:
+          name: dotnet-results-${{ matrix.dotnet-version }}
+          path: TestResults-${{ matrix.dotnet-version }}
+        # Use always() to always run this step to publish test results when there are test failures
+        if: ${{ always() }}
+```
+{% endraw %}
+
+### Publishing to package registries
+
+You can configure your workflow to publish your Dotnet package to a package registry when your CI tests pass. You can use repository secrets to store any tokens or credentials needed to publish your binary. The following example creates and publishes a package to {% data variables.product.prodname_registry %} using `dotnet core cli`.
+
+{% raw %}
+```yaml
+name: Upload dotnet package
+
+on:
+  release:
+    types: [created]
+
+jobs:
+  deploy:
+    runs-on: ubuntu-latest
+    steps:
+    - uses: actions/checkout@v2
+    - uses: actions/setup-dotnet@v1
+    with:
+        dotnet-version: '3.1.x' # SDK Version to use.
+        source-url: https://nuget.pkg.github.com/<owner>/index.json
+    env:
+        NUGET_AUTH_TOKEN: ${{secrets.GITHUB_TOKEN}}
+    - run: dotnet build <my project>
+    - name: Create the package
+    run: dotnet pack --configuration Release <my project>
+    - name: Publish the package to GPR
+    run: dotnet nuget push <my project>/bin/Release/*.nupkg
+```
+{% endraw %}

content/actions/guides/index.md

@@ -28,6 +28,7 @@ layout: product-sublanding
 <!-- {% link_in_list /about-continuous-integration %} -->
 <!-- {% link_in_list /setting-up-continuous-integration-using-workflow-templates %} -->
 <!-- {% link_in_list /building-and-testing-nodejs %} -->
+<!-- {% link_in_list /building-and-testing-net %} -->
 <!-- {% link_in_list /building-and-testing-powershell %} -->
 <!-- {% link_in_list /building-and-testing-python %} -->
 <!-- {% link_in_list /building-and-testing-ruby %} -->

content/actions/learn-github-actions/introduction-to-github-actions.md

@@ -147,7 +147,7 @@ To help you understand how YAML syntax is used to create a workflow file, this s
   ```
 </td>
 <td>
-  Groups together all the steps that run in the <code>check-bats-version</code> job. Each line nested under this section is a separate action.
+  Groups together all the steps that run in the <code>check-bats-version</code> job. Each item nested under this section is a separate action or shell command.
 </td>
 </tr>
 <tr>

content/actions/learn-github-actions/migrating-from-azure-pipelines-to-github-actions.md

@@ -62,16 +62,16 @@ Azure Pipelines
 {% raw %}
 ```yaml
 jobs:
-- job: scripts
-  pool:
-    vmImage: 'windows-latest'
-  steps:
-  - script: echo "This step runs in the default shell"
-  - bash: echo "This step runs in bash"
-  - pwsh: Write-Host "This step runs in PowerShell Core"
-  - task: PowerShell@2
-    inputs:
-      script: Write-Host "This step runs in PowerShell"
+  - job: scripts
+    pool:
+      vmImage: 'windows-latest'
+    steps:
+      - script: echo "This step runs in the default shell"
+      - bash: echo "This step runs in bash"
+      - pwsh: Write-Host "This step runs in PowerShell Core"
+      - task: PowerShell@2
+        inputs:
+          script: Write-Host "This step runs in PowerShell"
 ```
 {% endraw %}
 </td>
@@ -82,13 +82,13 @@ jobs:
   scripts:
     runs-on: windows-latest
     steps:
-    - run: echo "This step runs in the default shell"
-    - run: echo "This step runs in bash"
-      shell: bash
-    - run: Write-Host "This step runs in PowerShell Core"
-      shell: pwsh
-    - run: Write-Host "This step runs in PowerShell"
-      shell: powershell
+      - run: echo "This step runs in the default shell"
+      - run: echo "This step runs in bash"
+        shell: bash
+      - run: Write-Host "This step runs in PowerShell Core"
+        shell: pwsh
+      - run: Write-Host "This step runs in PowerShell"
+        shell: powershell
 ```
 {% endraw %}
 </td>
@@ -123,11 +123,11 @@ Azure Pipelines
 {% raw %}
 ```yaml
 jobs:
-- job: run_command
-  pool:
-    vmImage: 'windows-latest'
-  steps:
-  - script: echo "This step runs in CMD on Windows by default"
+  - job: run_command
+    pool:
+      vmImage: 'windows-latest'
+    steps:
+      - script: echo "This step runs in CMD on Windows by default"
 ```
 {% endraw %}
 </td>
@@ -138,9 +138,9 @@ jobs:
   run_command:
     runs-on: windows-latest
     steps:
-    - run: echo "This step runs in PowerShell on Windows by default"
-    - run: echo "This step runs in CMD on Windows explicitly"
-      shell: cmd
+      - run: echo "This step runs in PowerShell on Windows by default"
+      - run: echo "This step runs in CMD on Windows explicitly"
+        shell: cmd
 ```
 {% endraw %}
 </td>
@@ -171,12 +171,12 @@ Azure Pipelines
 {% raw %}
 ```yaml
 jobs:
-- job: conditional
-  pool:
-    vmImage: 'ubuntu-latest'
-  steps:
-  - script: echo "This step runs with str equals 'ABC' and num equals 123"
-    condition: and(eq(variables.str, 'ABC'), eq(variables.num, 123))
+  - job: conditional
+    pool:
+      vmImage: 'ubuntu-latest'
+    steps:
+      - script: echo "This step runs with str equals 'ABC' and num equals 123"
+        condition: and(eq(variables.str, 'ABC'), eq(variables.num, 123))
 ```
 {% endraw %}
 </td>
@@ -187,8 +187,8 @@ jobs:
   conditional:
     runs-on: ubuntu-latest
     steps:
-    - run: echo "This step runs with str equals 'ABC' and num equals 123"
-      if: ${{ env.str == 'ABC' && env.num == 123 }}
+      - run: echo "This step runs with str equals 'ABC' and num equals 123"
+        if: ${{ env.str == 'ABC' && env.num == 123 }}
 ```
 {% endraw %}
 </td>
@@ -217,29 +217,29 @@ Azure Pipelines
 {% raw %}
 ```yaml
 jobs:
-- job: initial
-  pool:
-    vmImage: 'ubuntu-latest'
-  steps:
-  - script: echo "This job will be run first."
-- job: fanout1
-  pool:
-    vmImage: 'ubuntu-latest'
-  dependsOn: initial
-  steps:
-  - script: echo "This job will run after the initial job, in parallel with fanout2."
-- job: fanout2
-  pool:
-    vmImage: 'ubuntu-latest'
-  dependsOn: initial
-  steps:
-  - script: echo "This job will run after the initial job, in parallel with fanout1."
-- job: fanin:
-  pool:
-    vmImage: 'ubuntu-latest'
-  dependsOn: [fanout1, fanout2]
-  steps:
-  - script: echo "This job will run after fanout1 and fanout2 have finished."
+  - job: initial
+    pool:
+      vmImage: 'ubuntu-latest'
+    steps:
+      - script: echo "This job will be run first."
+  - job: fanout1
+    pool:
+      vmImage: 'ubuntu-latest'
+    dependsOn: initial
+    steps:
+      - script: echo "This job will run after the initial job, in parallel with fanout2."
+  - job: fanout2
+    pool:
+      vmImage: 'ubuntu-latest'
+    dependsOn: initial
+    steps:
+      - script: echo "This job will run after the initial job, in parallel with fanout1."
+  - job: fanin:
+    pool:
+      vmImage: 'ubuntu-latest'
+    dependsOn: [fanout1, fanout2]
+    steps:
+      - script: echo "This job will run after fanout1 and fanout2 have finished."
 ```
 {% endraw %}
 </td>
@@ -250,22 +250,22 @@ jobs:
   initial:
     runs-on: ubuntu-latest
     steps:
-    - run: echo "This job will be run first."
+      - run: echo "This job will be run first."
   fanout1:
     runs-on: ubuntu-latest
     needs: initial
     steps:
-    - run: echo "This job will run after the initial job, in parallel with fanout2."
+      - run: echo "This job will run after the initial job, in parallel with fanout2."
   fanout2:
     runs-on: ubuntu-latest
     needs: initial
     steps:
-    - run: echo "This job will run after the initial job, in parallel with fanout1."
+      - run: echo "This job will run after the initial job, in parallel with fanout1."
   fanin:
     runs-on: ubuntu-latest
     needs: [fanout1, fanout2]
     steps:
-    - run: echo "This job will run after fanout1 and fanout2 have finished."
+      - run: echo "This job will run after fanout1 and fanout2 have finished."
 ```
 {% endraw %}
 </td>
@@ -294,15 +294,15 @@ Azure Pipelines
 {% raw %}
 ```yaml
 jobs:
-- job: run_python
-  pool:
-    vmImage: 'ubuntu-latest'
-  steps:
-  - task: UsePythonVersion@0
-    inputs:
-      versionSpec: '3.7'
-      architecture: 'x64'
-  - script: python script.py
+  - job: run_python
+    pool:
+      vmImage: 'ubuntu-latest'
+    steps:
+      - task: UsePythonVersion@0
+        inputs:
+          versionSpec: '3.7'
+          architecture: 'x64'
+      - script: python script.py
 ```
 {% endraw %}
 </td>
@@ -313,11 +313,11 @@ jobs:
   run_python:
     runs-on: ubuntu-latest
     steps:
-    - uses: actions/setup-python@v2
-      with:
-        python-version: '3.7'
-        architecture: 'x64'
-    - run: python script.py
+      - uses: actions/setup-python@v2
+        with:
+          python-version: '3.7'
+          architecture: 'x64'
+      - run: python script.py
 ```
 {% endraw %}
 </td>

content/actions/learn-github-actions/migrating-from-circleci-to-github-actions.md

@@ -258,24 +258,24 @@ jobs:
           POSTGRES_DB: ruby25
           POSTGRES_PASSWORD: ""
         ports:
-        - 5432:5432
+          - 5432:5432
         # Add a health check
         options: --health-cmd pg_isready --health-interval 10s --health-timeout 5s --health-retries 5
 
     steps:
-    # This Docker file changes sets USER to circleci instead of using the default user, so we need to update file permissions for this image to work on GH Actions.
-    # See https://docs.github.com/actions/reference/virtual-environments-for-github-hosted-runners#docker-container-filesystem
-    - name: Setup file system permissions
-      run: sudo chmod -R 777 $GITHUB_WORKSPACE /github /__w/_temp
-    - uses: actions/checkout@v2
-    - name: Install dependencies
-      run: bundle install --path vendor/bundle
-    - name: Setup environment configuration
-      run: cp .sample.env .env
-    - name: Setup database
-      run: bundle exec rake db:setup
-    - name: Run tests
-      run: bundle exec rake
+      # This Docker file changes sets USER to circleci instead of using the default user, so we need to update file permissions for this image to work on GH Actions.
+      # See https://docs.github.com/actions/reference/virtual-environments-for-github-hosted-runners#docker-container-filesystem
+      - name: Setup file system permissions
+        run: sudo chmod -R 777 $GITHUB_WORKSPACE /github /__w/_temp
+      - uses: actions/checkout@v2
+      - name: Install dependencies
+        run: bundle install --path vendor/bundle
+      - name: Setup environment configuration
+        run: cp .sample.env .env
+      - name: Setup database
+        run: bundle exec rake db:setup
+      - name: Run tests
+        run: bundle exec rake
 ```
 {% endraw %}
 </td>
@@ -412,35 +412,35 @@ jobs:
           POSTGRES_DB: ruby25
           POSTGRES_PASSWORD: ""
         ports:
-        - 5432:5432
+          - 5432:5432
         # Add a health check
         options: --health-cmd pg_isready --health-interval 10s --health-timeout 5s --health-retries 5
 
     steps:
-    - uses: actions/checkout@v2
-    - name: Setup Ruby
-      uses: eregon/use-ruby-action@master
-      with:
-        ruby-version: ${{ matrix.ruby }}
-    - name: Cache dependencies
-      uses: actions/cache@v2
-      with:
-        path: vendor/bundle
-        key: administrate-${{ matrix.image }}-${{ hashFiles('Gemfile.lock') }}
-    - name: Install postgres headers
-      run: sudo apt-get install libpq-dev
-    - name: Install dependencies
-      run: bundle install --path vendor/bundle
-    - name: Setup environment configuration
-      run: cp .sample.env .env
-    - name: Setup database
-      run: bundle exec rake db:setup
-    - name: Run tests
-      run: bundle exec rake
-    - name: Install appraisal
-      run: bundle exec appraisal install
-    - name: Run appraisal
-      run: bundle exec appraisal rake
+      - uses: actions/checkout@v2
+      - name: Setup Ruby
+        uses: eregon/use-ruby-action@master
+        with:
+          ruby-version: ${{ matrix.ruby }}
+      - name: Cache dependencies
+        uses: actions/cache@v2
+        with:
+          path: vendor/bundle
+          key: administrate-${{ matrix.image }}-${{ hashFiles('Gemfile.lock') }}
+      - name: Install postgres headers
+        run: sudo apt-get install libpq-dev
+      - name: Install dependencies
+        run: bundle install --path vendor/bundle
+      - name: Setup environment configuration
+        run: cp .sample.env .env
+      - name: Setup database
+        run: bundle exec rake db:setup
+      - name: Run tests
+        run: bundle exec rake
+      - name: Install appraisal
+        run: bundle exec appraisal install
+      - name: Run appraisal
+        run: bundle exec appraisal rake
 ```
 {% endraw %}
 </td>

content/actions/learn-github-actions/migrating-from-gitlab-cicd-to-github-actions.md

@@ -60,8 +60,8 @@ job1:
 jobs:
   job1:
     steps:
-    - uses: actions/checkout@v2
-    - run: echo "Run your script here"
+      - uses: actions/checkout@v2
+      - run: echo "Run your script here"
 ```
 {% endraw %}
 </td>
@@ -257,24 +257,24 @@ jobs:
   build_a:
     runs-on: ubuntu-latest
     steps:
-    - run: echo "This job will be run first."
+      - run: echo "This job will be run first."
 
   build_b:
     runs-on: ubuntu-latest
     steps:
-    - run: echo "This job will be run first, in parallel with build_a"
+      - run: echo "This job will be run first, in parallel with build_a"
 
   test_ab:
     runs-on: ubuntu-latest
     needs: [build_a,build_b]
     steps:
-    - run: echo "This job will run after build_a and build_b have finished"
+      - run: echo "This job will run after build_a and build_b have finished"
 
   deploy_ab:
     runs-on: ubuntu-latest
     needs: [test_ab]
     steps:
-    - run: echo "This job will run after test_ab is complete"
+      - run: echo "This job will run after test_ab is complete"
 ```
 {% endraw %}
 </td>
@@ -335,12 +335,12 @@ test_async:
 ```yaml
 jobs:
   test_async:
-  - name: Cache node modules
-    uses: actions/cache@v2
-    with:
-      path: ~/.npm
-      key: v1-npm-deps-${{ hashFiles('**/package-lock.json') }}
-      restore-keys: v1-npm-deps-
+    - name: Cache node modules
+      uses: actions/cache@v2
+      with:
+        path: ~/.npm
+        key: v1-npm-deps-${{ hashFiles('**/package-lock.json') }}
+        restore-keys: v1-npm-deps-
 ```
 {% endraw %}
 </td>
@@ -371,7 +371,7 @@ GitLab CI/CD
 script:
 artifacts:
   paths:
-  - math-homework.txt
+    - math-homework.txt
 ```
 {% endraw %}
 </td>
@@ -424,12 +424,12 @@ container-job:
   services:
     - postgres
   script:
-  # Performs a clean installation of all dependencies
-  # in the `package.json` file
-   - npm ci
-   # Runs a script that creates a PostgreSQL client,
-   # populates the client with data, and retrieves data
-   - node client.js
+    # Performs a clean installation of all dependencies
+    # in the `package.json` file
+    - npm ci
+    # Runs a script that creates a PostgreSQL client,
+    # populates the client with data, and retrieves data
+    - node client.js
   tags:
     - docker
 ```

content/actions/learn-github-actions/migrating-from-jenkins-to-github-actions.md

@@ -36,21 +36,20 @@ Jenkins lets you send builds to a single build agent, or you can distribute them
 
 Similarly, {% data variables.product.prodname_actions %} can send jobs to {% data variables.product.prodname_dotcom %}-hosted or self-hosted runners, and you can use labels to classify runners according to various attributes. The following table compares how the distributed build concept is implemented for both Jenkins and {% data variables.product.prodname_actions %}.
 
-| Jenkins       |  {% data variables.product.prodname_actions %}       |
+| Jenkins       | {% data variables.product.prodname_actions %} |
 | ------------- | ------------- |
-| [`agents`](https://wiki.jenkins.io/display/JENKINS/Distributed+builds)        | [`runners`](/actions/learn-github-actions/introduction-to-github-actions#runners)  <br> [`self-hosted runners`](/actions/hosting-your-own-runners/about-self-hosted-runners)|
+| [`agents`](https://wiki.jenkins.io/display/JENKINS/Distributed+builds) | [`runners`](/actions/learn-github-actions/introduction-to-github-actions#runners) <br> [`self-hosted runners`](/actions/hosting-your-own-runners/about-self-hosted-runners) |
 
 #### Using sections to organize pipelines
 
 Jenkins splits its Declarative Pipelines into multiple sections. Similarly, {% data variables.product.prodname_actions %} organizes its workflows into separate sections. The table below compares Jenkins sections with the {% data variables.product.prodname_actions %} workflow.
 
-|Jenkins Directives | {% data variables.product.prodname_actions %} |
+| Jenkins Directives | {% data variables.product.prodname_actions %} |
 | ------------- | ------------- |
-| [`agent`](https://jenkins.io/doc/book/pipeline/syntax/#agent)        | [`jobs.<job_id>.runs-on`](/actions/automating-your-workflow-with-github-actions/workflow-syntax-for-github-actions#jobsjob_idruns-on) <br> [`jobs.<job_id>.container`](/actions/automating-your-workflow-with-github-actions/workflow-syntax-for-github-actions#jobsjob_idcontainer)|
-| [`post`](https://jenkins.io/doc/book/pipeline/syntax/#post)          |               |
-| [`stages`](https://jenkins.io/doc/book/pipeline/syntax/#stages)          |     [`jobs`](/actions/automating-your-workflow-with-github-actions/workflow-syntax-for-github-actions#jobs)          |
-| [`steps`](https://jenkins.io/doc/book/pipeline/syntax/#steps)          |     [`jobs.<job_id>.steps`](/actions/automating-your-workflow-with-github-actions/workflow-syntax-for-github-actions#jobsjob_idsteps)          |
-
+| [`agent`](https://jenkins.io/doc/book/pipeline/syntax/#agent)   | [`jobs.<job_id>.runs-on`](/actions/automating-your-workflow-with-github-actions/workflow-syntax-for-github-actions#jobsjob_idruns-on) <br> [`jobs.<job_id>.container`](/actions/automating-your-workflow-with-github-actions/workflow-syntax-for-github-actions#jobsjob_idcontainer) |
+| [`post`](https://jenkins.io/doc/book/pipeline/syntax/#post)     |  |
+| [`stages`](https://jenkins.io/doc/book/pipeline/syntax/#stages) | [`jobs`](/actions/automating-your-workflow-with-github-actions/workflow-syntax-for-github-actions#jobs) |
+| [`steps`](https://jenkins.io/doc/book/pipeline/syntax/#steps)   | [`jobs.<job_id>.steps`](/actions/automating-your-workflow-with-github-actions/workflow-syntax-for-github-actions#jobsjob_idsteps) |
 
 ### Using directives
 
@@ -58,17 +57,16 @@ Jenkins uses directives to manage _Declarative Pipelines_. These directives defi
 
 | Jenkins Directives | {% data variables.product.prodname_actions %} |
 | ------------- | ------------- |
-| [`environment`](https://jenkins.io/doc/book/pipeline/syntax/#environment)  |  [`jobs.<job_id>.env`](/actions/automating-your-workflow-with-github-actions/workflow-syntax-for-github-actions#env) <br> [`jobs.<job_id>.steps[*].env`](/actions/automating-your-workflow-with-github-actions/workflow-syntax-for-github-actions#jobsjob_idstepsenv) |
-|  [`options`](https://jenkins.io/doc/book/pipeline/syntax/#parameters) |  [`jobs.<job_id>.strategy`](/actions/automating-your-workflow-with-github-actions/workflow-syntax-for-github-actions#jobsjob_idstrategy) <br> [`jobs.<job_id>.strategy.fail-fast`](/actions/automating-your-workflow-with-github-actions/workflow-syntax-for-github-actions#jobsjob_idstrategyfail-fast) <br> [`jobs.<job_id>.timeout-minutes`](/actions/automating-your-workflow-with-github-actions/workflow-syntax-for-github-actions#jobsjob_idtimeout-minutes)|
-| [`parameters`](https://jenkins.io/doc/book/pipeline/syntax/#parameters)  | [`inputs`](/actions/creating-actions/metadata-syntax-for-github-actions#inputs) <br> [`outputs`](/actions/creating-actions/metadata-syntax-for-github-actions#outputs) |
-| [`triggers`](https://jenkins.io/doc/book/pipeline/syntax/#triggers)  | [`on`](/actions/automating-your-workflow-with-github-actions/workflow-syntax-for-github-actions#on) <br> [`on.<event_name>.types`](/actions/automating-your-workflow-with-github-actions/workflow-syntax-for-github-actions#onevent_nametypes) <br> [<code>on.<push\|pull_request>.<branches\|tags></code>](/actions/automating-your-workflow-with-github-actions/workflow-syntax-for-github-actions#onpushpull_requestbranchestags) <br> [<code>on.<push\|pull_request>.paths</code>](/actions/automating-your-workflow-with-github-actions/workflow-syntax-for-github-actions#onpushpull_requestpaths) |
-|  [`triggers { upstreamprojects() }`](https://jenkins.io/doc/book/pipeline/syntax/#triggers) |  [`jobs.<job_id>.needs`](/actions/automating-your-workflow-with-github-actions/workflow-syntax-for-github-actions#jobsjob_idneeds) |
-| [Jenkins cron syntax](https://jenkins.io/doc/book/pipeline/syntax/#cron-syntax)  |  [`on.schedule`](/actions/automating-your-workflow-with-github-actions/workflow-syntax-for-github-actions#onschedule) |
-| [`stage`](https://jenkins.io/doc/book/pipeline/syntax/#stage)  |  [`jobs.<job_id>`](/actions/automating-your-workflow-with-github-actions/workflow-syntax-for-github-actions#jobsjob_id) <br> [`jobs.<job_id>.name`](/actions/automating-your-workflow-with-github-actions/workflow-syntax-for-github-actions#jobsjob_idname)|
-| [`tools`](https://jenkins.io/doc/book/pipeline/syntax/#tools)  |  [Specifications for {% data variables.product.prodname_dotcom %}-hosted runners](/actions/reference/specifications-for-github-hosted-runners/#supported-software) |
-|  [`input`](https://jenkins.io/doc/book/pipeline/syntax/#input) | [`inputs`](/actions/automating-your-workflow-with-github-actions/metadata-syntax-for-github-actions#inputs)  |
-| [`when`](https://jenkins.io/doc/book/pipeline/syntax/#when)  |  [`jobs.<job_id>.if`](/actions/automating-your-workflow-with-github-actions/workflow-syntax-for-github-actions#jobsjob_idif) |
-
+| [`environment`](https://jenkins.io/doc/book/pipeline/syntax/#environment)                  | [`jobs.<job_id>.env`](/actions/automating-your-workflow-with-github-actions/workflow-syntax-for-github-actions#env) <br> [`jobs.<job_id>.steps[*].env`](/actions/automating-your-workflow-with-github-actions/workflow-syntax-for-github-actions#jobsjob_idstepsenv) |
+| [`options`](https://jenkins.io/doc/book/pipeline/syntax/#parameters)                       | [`jobs.<job_id>.strategy`](/actions/automating-your-workflow-with-github-actions/workflow-syntax-for-github-actions#jobsjob_idstrategy) <br> [`jobs.<job_id>.strategy.fail-fast`](/actions/automating-your-workflow-with-github-actions/workflow-syntax-for-github-actions#jobsjob_idstrategyfail-fast) <br> [`jobs.<job_id>.timeout-minutes`](/actions/automating-your-workflow-with-github-actions/workflow-syntax-for-github-actions#jobsjob_idtimeout-minutes) |
+| [`parameters`](https://jenkins.io/doc/book/pipeline/syntax/#parameters)                    | [`inputs`](/actions/creating-actions/metadata-syntax-for-github-actions#inputs) <br> [`outputs`](/actions/creating-actions/metadata-syntax-for-github-actions#outputs) |
+| [`triggers`](https://jenkins.io/doc/book/pipeline/syntax/#triggers)                        | [`on`](/actions/automating-your-workflow-with-github-actions/workflow-syntax-for-github-actions#on) <br> [`on.<event_name>.types`](/actions/automating-your-workflow-with-github-actions/workflow-syntax-for-github-actions#onevent_nametypes) <br> [<code>on.<push\|pull_request>.<branches\|tags></code>](/actions/automating-your-workflow-with-github-actions/workflow-syntax-for-github-actions#onpushpull_requestbranchestags) <br> [<code>on.<push\|pull_request>.paths</code>](/actions/automating-your-workflow-with-github-actions/workflow-syntax-for-github-actions#onpushpull_requestpaths) |
+| [`triggers { upstreamprojects() }`](https://jenkins.io/doc/book/pipeline/syntax/#triggers) | [`jobs.<job_id>.needs`](/actions/automating-your-workflow-with-github-actions/workflow-syntax-for-github-actions#jobsjob_idneeds) |
+| [Jenkins cron syntax](https://jenkins.io/doc/book/pipeline/syntax/#cron-syntax)            | [`on.schedule`](/actions/automating-your-workflow-with-github-actions/workflow-syntax-for-github-actions#onschedule) |
+| [`stage`](https://jenkins.io/doc/book/pipeline/syntax/#stage)                              | [`jobs.<job_id>`](/actions/automating-your-workflow-with-github-actions/workflow-syntax-for-github-actions#jobsjob_id) <br> [`jobs.<job_id>.name`](/actions/automating-your-workflow-with-github-actions/workflow-syntax-for-github-actions#jobsjob_idname) |
+| [`tools`](https://jenkins.io/doc/book/pipeline/syntax/#tools)                              | [Specifications for {% data variables.product.prodname_dotcom %}-hosted runners](/actions/reference/specifications-for-github-hosted-runners/#supported-software) |
+| [`input`](https://jenkins.io/doc/book/pipeline/syntax/#input)                              | [`inputs`](/actions/automating-your-workflow-with-github-actions/metadata-syntax-for-github-actions#inputs) |
+| [`when`](https://jenkins.io/doc/book/pipeline/syntax/#when)                                | [`jobs.<job_id>.if`](/actions/automating-your-workflow-with-github-actions/workflow-syntax-for-github-actions#jobsjob_idif) |
 
 ### Using sequential stages
 
@@ -84,19 +82,19 @@ Jenkins can run the `stages` and `steps` in parallel, while {% data variables.pr
 
 Both {% data variables.product.prodname_actions %} and Jenkins let you use a build matrix to define various system combinations.
 
-| Jenkins  | {% data variables.product.prodname_actions %} |
+| Jenkins       | {% data variables.product.prodname_actions %} |
 | ------------- | ------------- |
-|  [`axis`](https://jenkins.io/doc/book/pipeline/syntax/#matrix-axes)  |  [`strategy/matrix`](/actions/learn-github-actions/managing-complex-workflows/#using-a-build-matrix) <br> [`context`](/actions/reference/context-and-expression-syntax-for-github-actions)   |
-|  [`stages`](https://jenkins.io/doc/book/pipeline/syntax/#matrix-stages)  |  [`steps-context`](/actions/reference/context-and-expression-syntax-for-github-actions#steps-context)  |
-|  [`excludes`](https://jenkins.io/doc/book/pipeline/syntax/#matrix-stages)  | |
+| [`axis`](https://jenkins.io/doc/book/pipeline/syntax/#matrix-axes)       | [`strategy/matrix`](/actions/learn-github-actions/managing-complex-workflows/#using-a-build-matrix) <br> [`context`](/actions/reference/context-and-expression-syntax-for-github-actions) |
+| [`stages`](https://jenkins.io/doc/book/pipeline/syntax/#matrix-stages)   | [`steps-context`](/actions/reference/context-and-expression-syntax-for-github-actions#steps-context) |
+| [`excludes`](https://jenkins.io/doc/book/pipeline/syntax/#matrix-stages) |  |
 
 #### Using steps to execute tasks
 
 Jenkins groups `steps` together in `stages`. Each of these steps can be a script, function, or command, among others. Similarly, {% data variables.product.prodname_actions %} uses `jobs` to execute specific groups of `steps`.
 
-| Jenkins steps  | {% data variables.product.prodname_actions %} |
+| Jenkins steps | {% data variables.product.prodname_actions %} |
 | ------------- | ------------- |
-|  [`script`](https://jenkins.io/doc/book/pipeline/syntax/#script)  |  [`jobs.<job_id>.steps`](/actions/reference/workflow-syntax-for-github-actions#jobsjob_idsteps)  |
+| [`script`](https://jenkins.io/doc/book/pipeline/syntax/#script) | [`jobs.<job_id>.steps`](/actions/reference/workflow-syntax-for-github-actions#jobsjob_idsteps) |
 
 ### Examples of common tasks
 
@@ -114,23 +112,23 @@ Jenkins Pipeline
 <tr>
 <td>
 
-  ```yaml
-    pipeline {
-     agent any
-      triggers {
-        cron('H/15 * * * 1-5')
-      }
-   }
-  ```
+```yaml
+pipeline {
+  agent any
+  triggers {
+    cron('H/15 * * * 1-5')
+  }
+}
+```
 
 </td>
 <td>
 
-  ```yaml
-  on:
+```yaml
+on:
   schedule:
-    - cron:  '*/15 * * * 1-5'
-  ```
+    - cron: '*/15 * * * 1-5'
+```
 
 </td>
 </tr>
@@ -150,25 +148,24 @@ Jenkins Pipeline
 <tr>
 <td>
 
-  ```yaml
-  pipeline {
-    agent any
-    environment {
-      MAVEN_PATH = '/usr/local/maven'
-    }
+```yaml
+pipeline {
+  agent any
+  environment {
+    MAVEN_PATH = '/usr/local/maven'
   }
-  ```
+}
+```
 
 </td>
 <td>
 
-  ```yaml
- jobs:
-    maven-build:
+```yaml
+jobs:
+  maven-build:
     env:
       MAVEN_PATH: '/usr/local/maven'
-
-  ```
+```
 
 </td>
 </tr>
@@ -188,30 +185,28 @@ Jenkins Pipeline
 <tr>
 <td>
 
-  ```yaml
-  pipeline {
-    triggers {
-      upstream(
-        upstreamProjects: 'job1,job2',
-        threshold: hudson.model.Result.SUCCESS)
-      }
-    }
+```yaml
+pipeline {
+  triggers {
+    upstream(
+      upstreamProjects: 'job1,job2',
+      threshold: hudson.model.Result.SUCCESS
+    )
   }
-
-  ```
+}
+```
 
 </td>
 <td>
 
-  ```yaml
-  jobs:
-    job1:
-    job2:
-      needs: job1
-    job3:
-      needs: [job1, job2]
-
-  ```
+```yaml
+jobs:
+  job1:
+  job2:
+    needs: job1
+  job3:
+    needs: [job1, job2]
+```
 
 </td>
 </tr>
@@ -231,26 +226,27 @@ Jenkins Pipeline
 <tr>
 <td>
 
-  ```yaml
+```yaml
 pipeline {
-agent none
-stages {
-  stage('Run Tests') {
-    matrix {
-      axes {
-        axis {
-          name: 'PLATFORM'
-          values: 'macos', 'linux'
+  agent none
+  stages {
+    stage('Run Tests') {
+      matrix {
+        axes {
+          axis {
+            name: 'PLATFORM'
+            values: 'macos', 'linux'
+          }
         }
-      }
-      agent { label "${PLATFORM}" }
-      stages {
-        stage('test') {
-          tools { nodejs "node-12" }
-          steps {
-            dir("scripts/myapp") {
-              sh(script: "npm install -g bats")
-              sh(script: "bats tests")
+        agent { label "${PLATFORM}" }
+        stages {
+          stage('test') {
+            tools { nodejs "node-12" }
+            steps {
+              dir("scripts/myapp") {
+                sh(script: "npm install -g bats")
+                sh(script: "bats tests")
+              }
             }
           }
         }
@@ -258,33 +254,32 @@ stages {
     }
   }
 }
-}
-  ```
+```
 
 </td>
 <td>
 
 {% raw %}
-  ```yaml
-  name: demo-workflow
-  on:
-    push:
-  jobs:
-    test:
-      runs-on: ${{ matrix.os }}
-      strategy:
-        fail-fast: false
-        matrix:
-          os: [macos-latest, ubuntu-latest]
-      steps:
-        - uses: actions/checkout@v1
-        - uses: actions/setup-node@v1
-          with:
-            node-version: 12
-        - run: npm install -g bats
-        - run: bats tests
-          working-directory: scripts/myapp
-  ```
+```yaml
+name: demo-workflow
+on:
+  push:
+jobs:
+  test:
+    runs-on: ${{ matrix.os }}
+    strategy:
+      fail-fast: false
+      matrix:
+        os: [macos-latest, ubuntu-latest]
+    steps:
+      - uses: actions/checkout@v1
+      - uses: actions/setup-node@v1
+        with:
+          node-version: 12
+      - run: npm install -g bats
+      - run: bats tests
+        working-directory: scripts/myapp
+```
 {% endraw %}
 
 </td>

content/actions/learn-github-actions/migrating-from-travis-ci-to-github-actions.md

@@ -70,8 +70,8 @@ Travis CI
 ```yaml
 matrix:
   include:
-  - rvm: 2.5
-  - rvm: 2.6.3
+    - rvm: 2.5
+    - rvm: 2.6.3
 ```
 {% endraw %}
 </td>
@@ -110,8 +110,8 @@ Travis CI
 ```yaml
 branches:
   only:
-  - main
-  - 'mona/octocat'
+    - main
+    - 'mona/octocat'
 ```
 {% endraw %}
 </td>
@@ -120,7 +120,7 @@ branches:
 ```yaml
 on:
   push:
-    branches:    
+    branches:
       - main
       - 'mona/octocat'
 ```
@@ -156,9 +156,9 @@ git:
 <td class="d-table-cell v-align-top">
 {% raw %}
 ```yaml
-    - uses: actions/checkout@v2
-      with:
-        submodules: false
+- uses: actions/checkout@v2
+  with:
+    submodules: false
 ```
 {% endraw %}
 </td>
@@ -208,10 +208,10 @@ When working with different languages in {% data variables.product.prodname_acti
 For example:
 
 ```yaml
-      steps:
-        - name: Run build script
-          run: ./.github/scripts/build.sh
-          shell: bash
+steps:
+  - name: Run build script
+    run: ./.github/scripts/build.sh
+    shell: bash
 ```
 
 ### Error handling in {% data variables.product.prodname_actions %}
@@ -276,11 +276,11 @@ jobs:
   run_python:
     runs-on: ubuntu-latest
     steps:
-    - uses: actions/setup-python@v2
-      with:
-        python-version: '3.7'
-        architecture: 'x64'
-    - run: python script.py
+      - uses: actions/setup-python@v2
+        with:
+          python-version: '3.7'
+          architecture: 'x64'
+      - run: python script.py
 ```
 {% endraw %}
 </td>
@@ -346,20 +346,20 @@ Travis CI
 <tr>
 <td>
 
-  ```yaml
+```yaml
 env:
   - MAVEN_PATH="/usr/local/maven"
-  ```
+```
 
 </td>
 <td>
 
-  ```yaml
- jobs:
-    maven-build:
-      env:
-        MAVEN_PATH: '/usr/local/maven'
-  ```
+```yaml
+jobs:
+  maven-build:
+    env:
+      MAVEN_PATH: '/usr/local/maven'
+```
 
 </td>
 </tr>
@@ -379,24 +379,24 @@ Travis CI
 <tr>
 <td>
 {% raw %}
-  ```yaml
+```yaml
 install:
-    - npm install
+  - npm install
 script:
-    - npm run build
-    - npm test
-  ```
+  - npm run build
+  - npm test
+```
 {% endraw %}
 </td>
 <td>
 {% raw %}
-  ```yaml
+```yaml
 name: Node.js CI
 on: [push]
 jobs:
-    build:
-      runs-on: ubuntu-latest
-      steps:
+  build:
+    runs-on: ubuntu-latest
+    steps:
       - uses: actions/checkout@v2
       - name: Use Node.js
         uses: actions/setup-node@v1
@@ -405,13 +405,12 @@ jobs:
       - run: npm install
       - run: npm run build
       - run: npm test
-  ```
+```
 {% endraw %}
 </td>
 </tr>
 </table>
 
-
 ### Next steps
 
 To continue learning about the main features of  {% data variables.product.prodname_actions %}, see "[Learn {% data variables.product.prodname_actions %}](/actions/learn-github-actions)."

content/actions/managing-workflow-runs/manually-running-a-workflow.md

@@ -18,7 +18,7 @@ To run a workflow manually, the workflow must be configured to run on the `workf
 
 To trigger the `workflow_dispatch` event on {% data variables.product.prodname_dotcom %}, your workflow must be in the default branch. Follow these steps to manually trigger a workflow run.
 
-{% data reusables.repositories.permissions-statement-read %}
+{% data reusables.repositories.permissions-statement-write %}
 
 {% data reusables.repositories.navigate-to-repo %}
 {% data reusables.repositories.actions-tab %}

content/actions/reference/context-and-expression-syntax-for-github-actions.md

@@ -111,15 +111,14 @@ The `github` context contains information about the workflow run and the event t
 
 The `env` context contains environment variables that have been set in a workflow, job, or step. For more information about setting environment variables in your workflow, see "[Workflow syntax for {% data variables.product.prodname_actions %}](/actions/automating-your-workflow-with-github-actions/workflow-syntax-for-github-actions#env)."
 
-The `env` context syntax allows you to use the value of an environment variable in your workflow file. If you want to use the value of an environment variable inside a runner, use the runner operating system's normal method for reading environment variables.
+The `env` context syntax allows you to use the value of an environment variable in your workflow file. You can use the `env` context in the value of any key in a **step** except for the `id` and `uses` keys. For more information on the step syntax, see "[Workflow syntax for {% data variables.product.prodname_actions %}](/actions/automating-your-workflow-with-github-actions/workflow-syntax-for-github-actions#jobsjob_idsteps)."
 
-You can only use the `env` context in the value of the `with` and `name` keys, or in a step's `if` conditional. For more information on the step syntax, see "[Workflow syntax for {% data variables.product.prodname_actions %}](/actions/automating-your-workflow-with-github-actions/workflow-syntax-for-github-actions#jobsjob_idsteps)."
+If you want to use the value of an environment variable inside a runner, use the runner operating system's normal method for reading environment variables.
 
 | Property name | Type | Description |
 |---------------|------|-------------|
 | `env` | `object` | This context changes for each step in a job. You can access this context from any step in a job. |
-| `env.<env name>` | `string` | The value of a specific environment variable. |
-
+| `env.<env_name>` | `string` | The value of a specific environment variable. |
 
 #### `job` context
 

content/actions/reference/workflow-syntax-for-github-actions.md

@@ -187,7 +187,7 @@ For more information about cron syntax, see "[Events that trigger workflows](/ac
 
 ### `env`
 
-A `map` of environment variables that are available to all jobs and steps in the workflow. You can also set environment variables that are only available to a job or step. For more information, see [`jobs.<job_id>.env`](#jobsjob_idenv) and [`jobs.<job_id>.steps[*].env`](#jobsjob_idstepsenv).
+A `map` of environment variables that are available to the steps of all jobs in the workflow. You can also set environment variables that are only available to the steps of a single job or to a single step. For more information, see [`jobs.<job_id>.env`](#jobsjob_idenv) and [`jobs.<job_id>.steps[*].env`](#jobsjob_idstepsenv).
 
 {% data reusables.repositories.actions-env-var-note %}
 
@@ -705,7 +705,7 @@ You can set the `shell` value to a template string using `command […options] {
 For built-in shell keywords, we provide the following defaults that are executed by {% data variables.product.prodname_dotcom %}-hosted runners. You should use these guidelines when running shell scripts.
 
 - `bash`/`sh`:
-  - Fail-fast behavior using `set -e o pipefail`: Default for `bash` and built-in `shell`. It is also the default when you don't provide an option on non-Windows platforms.
+  - Fail-fast behavior using `set -eo pipefail`: Default for `bash` and built-in `shell`. It is also the default when you don't provide an option on non-Windows platforms.
   - You can opt out of fail-fast and take full control by providing a template string to the shell options. For example, `bash {0}`.
   - sh-like shells exit with the exit code of the last command executed in a script, which is also the default behavior for actions. The runner will report the status of the step as fail/succeed based on this exit code.
 

content/developers/apps/creating-ci-tests-with-the-checks-api.md

@@ -24,7 +24,7 @@ A CI server hosts code that runs CI tests such as code linters (which check styl
 
 The [Checks API](/rest/reference/checks) allows you to set up CI tests that are automatically run against each code commit in a repository. The Checks API reports detailed information about each check on GitHub in the pull request's **Checks** tab. With the Checks API, you can create annotations with additional details for specific lines of code. Annotations are visible in the **Checks** tab. When you create an annotation for a file that is part of the pull request, the annotations are also shown in the **Files changed** tab.
 
-A _check suite_ is a group of _check runs_ (individual CI tests). Both the suite and the runs contain _statuses_ that are visible in a pull request on GitHub. You can use statuses to determine when a code commit introduces errors. Using these statuses with [protected branches](/rest/reference/repos#branches) can prevent people from merging pull requests prematurely. See "[Enabling required status checks](/articles/enabling-required-status-checks/)" for more details.
+A _check suite_ is a group of _check runs_ (individual CI tests). Both the suite and the runs contain _statuses_ that are visible in a pull request on GitHub. You can use statuses to determine when a code commit introduces errors. Using these statuses with [protected branches](/rest/reference/repos#branches) can prevent people from merging pull requests prematurely. See "[About protected branches](/github/administering-a-repository/about-protected-branches#require-status-checks-before-merging)" for more details.
 
 The Checks API sends the [`check_suite` webhook event](/webhooks/event-payloads/#check_suite) to all GitHub Apps installed on a repository each time new code is pushed to the repository. To receive all Checks API event actions, the app must have the `checks:write` permission. GitHub automatically creates `check_suite` events for new code commits in a repository using the default flow, although [Update repository preferences for check suites](/rest/reference/checks#update-repository-preferences-for-check-suites) if you'd like. Here's how the default flow works:
 

content/developers/apps/scopes-for-oauth-apps.md

@@ -46,8 +46,8 @@ Name | Description
  `repo_deployment`| Grants access to [deployment statuses](/rest/reference/repos#deployments) for public and private repositories. This scope is only necessary to grant other users or services access to deployment statuses, *without* granting access to the code.
  `public_repo`| Limits access to public repositories. That includes read/write access to code, commit statuses, repository projects, collaborators, and deployment statuses for public repositories and organizations. Also required for starring public repositories.
  `repo:invite` | Grants accept/decline abilities for invitations to collaborate on a repository. This scope is only necessary to grant other users or services access to invites *without* granting access to the code.{% if currentVersion == "free-pro-team@latest" or currentVersion ver_gt "enterprise-server@3.0" %}
-&emsp;`security_events` | Grants: <br/> read and write access to security events in the [{% data variables.product.prodname_code_scanning %} API](/rest/reference/code-scanning). <br/> read and write access to security events in the [{% data variables.product.prodname_secret_scanning %} API](/rest/reference/secret-scanning).{% endif %}{% if currentVersion ver_gt "enterprise-server@2.21" and currentVersion ver_lt "enterprise-server@3.1" %}
-&emsp;`security_events` | Grants read and write access to security events in the [{% data variables.product.prodname_code_scanning %} API](/rest/reference/code-scanning).{% endif %}
+&emsp;`security_events` | Grants: <br/> read and write access to security events in the [{% data variables.product.prodname_code_scanning %} API](/rest/reference/code-scanning) <br/> read and write access to security events in the [{% data variables.product.prodname_secret_scanning %} API](/rest/reference/secret-scanning) <br/> This scope is only necessary to grant other users or services access to security events *without* granting access to the code.{% endif %}{% if currentVersion ver_gt "enterprise-server@2.21" and currentVersion ver_lt "enterprise-server@3.1" %}
+&emsp;`security_events` | Grants read and write access to security events in the [{% data variables.product.prodname_code_scanning %} API](/rest/reference/code-scanning). This scope is only necessary to grant other users or services access to security events *without* granting access to the code.{% endif %}
 **`admin:repo_hook`** | Grants read, write, ping, and delete access to repository hooks in public and private repositories. The `repo` and `public_repo` scopes grants full access to repositories, including repository hooks. Use the `admin:repo_hook` scope to limit access to only repository hooks.
 &emsp;`write:repo_hook` | Grants read, write, and ping access to hooks in public or private repositories.
 &emsp;`read:repo_hook`| Grants read and ping access to hooks in public or private repositories.

content/github/administering-a-repository/about-branch-restrictions.md

@@ -1,30 +0,0 @@
----
-title: About branch restrictions
-intro: 'Branches within repositories that belong to organizations can be configured so that only certain users, teams, or apps can push to the branch.'
-product: '{% data reusables.gated-features.branch-restrictions %}'
-redirect_from:
-  - /articles/about-branch-restrictions
-versions:
-  free-pro-team: '*'
-  enterprise-server: '*'
-  github-ae: '*'
----
-
-When you enable branch restrictions, only users, teams, or apps that have been given permission can push to the protected branch. For more information, see "[Enabling branch restrictions](/articles/enabling-branch-restrictions)" and "[About protected branches](/articles/about-protected-branches)." You can view and edit the users, teams, or apps with push access to a protected branch in the protected branch's settings.
-
-You can only give push access to a protected branch to users, teams, or installed {% data variables.product.prodname_github_apps %} with `write` access to a repository.
-
-People and apps with admin permissions to a repository are always able to push to a protected branch.
-
-{% tip %}
-
-**Note:** If "Include administrators" is selected, you've enabled required status checks on the branch, and if any status checks fail, any attempt to push changes to the protected branch will also fail, even for people and apps with admin permissions. For more information, see "[Enabling required status checks](/articles/enabling-required-status-checks)."
-
-{% endtip %}
-
-### Further reading
-
-- "[About protected branches](/articles/about-protected-branches)"
-- "[Configuring protected branches](/articles/configuring-protected-branches)"
-- "[About required status checks](/articles/about-required-status-checks)"
-- "[Enabling required status checks](/articles/enabling-required-status-checks)"

content/github/administering-a-repository/about-merge-methods-on-github.md

@@ -14,7 +14,7 @@ versions:
 {% data reusables.pull_requests.default_merge_option %}
 
 {% if currentVersion == "free-pro-team@latest" or currentVersion == "github-ae@latest" or currentVersion ver_gt "enterprise-server@2.19" %}
-The default merge method creates a merge commit. You can prevent anyone from pushing merge commits to a protected branch by enforcing a linear commit history. For more information, see "[Requiring a linear commit history](/github/administering-a-repository/requiring-a-linear-commit-history)."{% endif %}
+The default merge method creates a merge commit. You can prevent anyone from pushing merge commits to a protected branch by enforcing a linear commit history. For more information, see "[About protected branches](/github/administering-a-repository/about-protected-branches#require-linear-history)."{% endif %}
 
 ### Squashing your merge commits
 

content/github/administering-a-repository/about-protected-branches.md

@@ -1,38 +1,141 @@
 ---
 title: About protected branches
-intro: 'Protected branches ensure that collaborators on your repository cannot make irrevocable changes to branches. Enabling protected branches also allows you to enable other optional checks and requirements, like required status checks and required reviews.'
+intro: 'You can protect important branches by setting branch protection rules, which define whether collaborators can delete or force push to the branch and set requirements for any pushes to the branch, such as passing status checks or a linear commit history.'
 product: '{% data reusables.gated-features.protected-branches %}'
 redirect_from:
   - /articles/about-protected-branches
   - /enterprise/admin/developer-workflow/about-protected-branches-and-required-status-checks
+  - /articles/about-branch-restrictions
+  - /github/administering-a-repository/about-branch-restrictions
+  - /articles/about-required-status-checks
+  - /github/administering-a-repository/about-required-status-checks
+  - /articles/types-of-required-status-checks
+  - /github/administering-a-repository/types-of-required-status-checks
+  - /articles/about-required-commit-signing
+  - /github/administering-a-repository/about-required-commit-signing
+  - /articles/about-required-reviews-for-pull-requests
+  - /github/administering-a-repository/about-required-reviews-for-pull-requests
 versions:
   free-pro-team: '*'
   enterprise-server: '*'
   github-ae: '*'
 ---
 
-### About protected branches
+### About branch protection rules
 
-{% data reusables.pull_requests.about-protected-branches %} You can choose to enforce restrictions on how a pull request is merged into your repository.
+You can enforce certain workflows or requirements before a collaborator can push changes to a branch in your repository, including merging a pull request into the branch, by creating a branch protection rule. 
 
-Repository owners and people with admin permissions for a repository can enforce certain workflows or requirements, before a collaborator can merge a branch in your repository by creating protected branch rules.
+By default, each branch protection rule disables force pushes to the matching branches and prevents the matching branches from being deleted. You can optionally disable these restrictions and enable additional branch protection settings.
 
-{% data reusables.repositories.branch-rules-example %} For more information, see "[Configuring protected branches](/articles/configuring-protected-branches/)."
+By default, the restrictions of a branch protection rule don't apply to people with admin permissions to the repository. You can optionally choose to include administrators, too.
+
+{% data reusables.repositories.branch-rules-example %} For more information about branch name patterns, see "[Managing a branch protection rule](/github/administering-a-repository/managing-a-branch-protection-rule)."
 
 {% data reusables.pull_requests.you-can-auto-merge %}
 
-### Prioritization of protected branch rules
+### About branch protection settings
 
-If a repository has multiple protected branch rules that affect the same branches, the rules that include a specific branch name have the highest priority. If there is more than one protected branch rule that references the same specific branch name, then the branch rule created first will have higher priority.
+For each branch protection rule, you can choose to enable or disable the following settings.
+- [Require pull request reviews before merging](#require-pull-request-reviews-before-merging)
+- [Require status checks before merging](#require-status-checks-before-merging)
+- [Require signed commits](#require-signed-commits)
+- [Require linear history](#require-linear-history)
+- [Include administrators](#include-administrators)
+- [Restrict who can push to matching branches](#restrict-who-can-push-to-matching-branches)
+- [Allow force pushes](#allow-force-pushes)
+- [Allow deletions](#allow-deletions)
 
-Protected branch rules that mention a special character, such as `*`, `?`, or `]`, are applied in the order they were created, so older rules with these characters have a higher priority.
+#### Require pull request reviews before merging
 
-### Branch protection settings
+{% data reusables.pull_requests.required-reviews-for-prs-summary %}
 
-When you create a branch protection rule in a repository, collaborators cannot force push to the protected branch or delete the branch{% if currentVersion == "free-pro-team@latest" %} by default{% endif %}. You can enable other branch protection settings. For information, see "[Defining the mergeability of pull requests](/github/administering-a-repository/defining-the-mergeability-of-pull-requests)."
+If you enable required reviews, collaborators can only push changes to a protected branch via a pull request that is approved by the required number of reviewers with write permissions.
 
-### Further reading
+If a person with admin permissions chooses the **Request changes** option in a review, then that person must approve the pull request before the pull request can be merged. If a reviewer who requests changes on a pull request isn't available, anyone with write permissions for the repository can dismiss the blocking review. 
 
-- "[About required status checks](/articles/about-required-status-checks)"
-- "[About required reviews for pull requests](/articles/about-required-reviews-for-pull-requests)"
-- "[About required commit signing](/articles/about-required-commit-signing)"
+{% data reusables.repositories.review-policy-overlapping-commits %}
+
+If a collaborator attempts to merge a pull request with pending or rejected reviews into the protected branch, the collaborator will receive an error message.
+
+```shell
+remote: error: GH006: Protected branch update failed for refs/heads/main.
+remote: error: Changes have been requested.
+```
+
+Optionally, you can choose to dismiss stale pull request approvals when commits are pushed. If anyone pushes a commit that modifies code to an approved pull request, the approval will be dismissed, and the pull request cannot be merged. This doesn't apply if the collaborator pushes commits that don't modify code, like merging the base branch into the pull request's branch. For information about the base branch, see "[About pull requests](/articles/about-pull-requests)."
+
+Optionally, you can restrict the ability to dismiss pull request reviews to specific people or teams. For more information, see "[Dismissing a pull request review](/articles/dismissing-a-pull-request-review)."
+
+Optionally, you can choose to require reviews from code owners. If you do, any pull request that affects code with a code owner must be approved by that code owner before the pull request can be merged into the protected branch.
+
+#### Require status checks before merging
+
+Required status checks ensure that all required CI tests are passing before collaborators can make changes to a protected branch. Required status checks can be checks or statuses. For more information, see "[About status checks](/github/collaborating-with-issues-and-pull-requests/about-status-checks)."
+
+Before you can enable required status checks, you must configure the repository to use the status API. For more information, see "[Repositories](/rest/reference/repos#statuses)" in the REST documentation.
+
+After enabling required status checks, all required status checks must pass before collaborators can merge changes into the protected branch. After all required status checks pass, any commits must either be pushed to another branch and then merged or pushed directly to the protected branch.
+
+{% note %}
+
+**Note:** Any person or integration with write permissions to a repository can set the state of any status check in the repository. {% data variables.product.company_short %} does not verify that the author of a check is authorized to create a check with a certain name or modify an existing status. Before merging a pull request, you should verify that the author of each status, listed in the merge box, is expected.
+
+{% endnote %}
+
+You can set up required status checks to either be "loose" or "strict." The type of required status check you choose determines whether your branch is required to be up-to-date with the base branch before merging.
+
+| Type of required status check | Setting | Merge requirements | Considerations |
+| --- | --- | --- | --- |
+| **Strict** | The **Require branches to be up-to-date before merging** checkbox is checked. | The branch **must** be up to date with the base branch before merging. | This is the default behavior for required status checks. More builds may be required, as you'll need to bring the head branch up to date after other collaborators merge pull requests to the protected base branch.|
+| **Loose** | The **Require branches to be up-to-date before merging** checkbox is **not** checked. | The branch **does not** have to be up to date with the base branch before merging. | You'll have fewer required builds, as you won't need to bring the head branch up to date after other collaborators merge pull requests. Status checks may fail after you merge your branch if there are incompatible changes with the base branch. |
+| **Disabled** | The **Require status checks to pass before merging** checkbox is **not** checked. | The branch has no merge restrictions. | If required status checks aren't enabled, collaborators can merge the branch at any time, regardless of whether it is up to date with the base branch. This increases the possibility of incompatible changes.
+
+For troubleshooting information, see "[Troubleshooting required status checks](/github/administering-a-repository/troubleshooting-required-status-checks)."
+
+#### Require signed commits
+
+When you enable required commit signing on a branch, contributors {% if currentVersion == "free-pro-team@latest" %}and bots{% endif %} can only push commits that have been signed and verified to the branch. For more information, see "[About commit signature verification](/articles/about-commit-signature-verification)."
+
+{% note %}
+
+**Note:** If a collaborator pushes an unsigned commit to a branch that requires commit signatures, the collaborator will need to rebase the commit to include a verified signature, then force push the rewritten commit to the branch.
+
+{% endnote %}
+
+You can always push local commits to the branch if the commits are signed and verified. {% if currentVersion == "free-pro-team@latest" %}You can also merge signed and verified commits into the branch using a pull request on {% data variables.product.product_name %}. However, you cannot squash and merge a pull request into the branch on {% data variables.product.product_name %} unless you are the author of the pull request.{% else %} However, you cannot merge pull requests into the branch on {% data variables.product.product_name %}.{% endif %} You can {% if currentVersion == "free-pro-team@latest" %}squash and {% endif %}merge pull requests locally. For more information, see "[Checking out pull requests locally](/github/collaborating-with-issues-and-pull-requests/checking-out-pull-requests-locally)."
+
+{% if currentVersion == "free-pro-team@latest" %} For more information about merge methods, see "[About merge methods on {% data variables.product.prodname_dotcom %}](/github/administering-a-repository/about-merge-methods-on-github)."{% endif %}
+
+#### Require linear history
+
+Enforcing a linear commit history prevents collaborators from pushing merge commits to the branch. This means that any pull requests merged into the protected branch must use a squash merge or a rebase merge. A strictly linear commit history can help teams reverse changes more easily. For more information about merge methods, see "[About pull request merges](/github/collaborating-with-issues-and-pull-requests/about-pull-request-merges)."
+
+Before you can require a linear commit history, your repository must allow squash merging or rebase merging. For more information, see "[Configuring pull request merges](/github/administering-a-repository/configuring-pull-request-merges)."
+
+#### Include administrators
+
+By default, protected branch rules do not apply to people with admin permissions to a repository. You can enable this setting to include administrators in your protected branch rules.
+
+#### Restrict who can push to matching branches
+
+{% if currentVersion == "free-pro-team@latest" %}
+You can enable branch restrictions if your repository is owned by an organization using {% data variables.product.prodname_team %} or {% data variables.product.prodname_ghe_cloud %}.
+{% endif %}
+
+When you enable branch restrictions, only users, teams, or apps that have been given permission can push to the protected branch. You can view and edit the users, teams, or apps with push access to a protected branch in the protected branch's settings.
+
+You can only give push access to a protected branch to users, teams, or installed {% data variables.product.prodname_github_apps %} with write access to a repository. People and apps with admin permissions to a repository are always able to push to a protected branch.
+
+#### Allow force pushes
+
+By default, {% data variables.product.product_name %} blocks force pushes on all protected branches. When you enable force pushes to a protected branch, anyone with at least write permissions to the repository can force push to the branch, including those with admin permissions.
+
+Enabling force pushes will not override any other branch protection rules. For example, if a branch requires a linear commit history, you cannot force push merge commits to that branch.
+
+{% if enterpriseServerVersions contains currentVersion or currentVersion == "github-ae@latest" %}You cannot enable force pushes for a protected branch if a site administrator has blocked force pushes to all branches in your repository. For more information, see "[Blocking force pushes to repositories owned by a user account or organization](/enterprise/{{ currentVersion }}/admin/developer-workflow/blocking-force-pushes-to-repositories-owned-by-a-user-account-or-organization)."
+
+If a site administrator has blocked force pushes to the default branch only, you can still enable force pushes for any other protected branch.{% endif %}
+
+#### Allow deletions
+
+By default, you cannot delete a protected branch. When you enable deletion of a protected branch, anyone with at least write permissions to the repository can delete the branch.

content/github/administering-a-repository/about-required-commit-signing.md

@@ -1,29 +0,0 @@
----
-title: About required commit signing
-intro: Required commit signing ensures that collaborators can only push verified signed commits to a protected branch.
-product: '{% data reusables.gated-features.protected-branches %}'
-redirect_from:
-  - /articles/about-required-commit-signing
-versions:
-  free-pro-team: '*'
-  enterprise-server: '*'
-  github-ae: '*'
----
-
-If you've enforced branch protections in your repository, you can set up required commit signing. For more information, see "[Configuring protected branches](/articles/configuring-protected-branches/)."
-
-When you enable required commit signing on a branch, contributors {% if currentVersion == "free-pro-team@latest" %}and bots{% endif %} can only push commits that have been signed and verified to the branch. For more information, see "[About commit signature verification](/articles/about-commit-signature-verification)."
-
-You can always push local commits to the branch if the commits are signed and verified. {% if currentVersion == "free-pro-team@latest" %}You can also merge signed and verified commits into the branch using a pull request on {% data variables.product.product_name %}. However, you cannot squash and merge a pull request into the branch on {% data variables.product.product_name %} unless you are the author of the pull request.{% else %} However, you cannot merge pull requests into the branch on {% data variables.product.product_name %}.{% endif %} You can {% if currentVersion == "free-pro-team@latest" %}squash and {% endif %}merge pull requests locally. For more information, see "[Checking out pull requests locally](/github/collaborating-with-issues-and-pull-requests/checking-out-pull-requests-locally)."{% if currentVersion == "free-pro-team@latest" %} For more information about merge methods, see "[About merge methods on {% data variables.product.prodname_dotcom %}](/github/administering-a-repository/about-merge-methods-on-github)."{% endif %}
-
-{% note %}
-
-**Note:** Enabling required commit signing on a branch will make it more difficult to contribute. If a collaborator pushes an unsigned commit to a branch that has required commit signing enabled, they will need to rebase their commit to include a verified signature and force push the rewritten commit to the branch.
-
-{% endnote %}
-
-Administrators of a repository can push local commits that have not been signed and verified, however you can require administrators to be subject to required commit signing. For more information, see "[Enabling required commit signing](/articles/enabling-required-commit-signing)."
-
-### Further reading
-
-- "[About protected branches](/articles/about-protected-branches)"

content/github/administering-a-repository/about-required-reviews-for-pull-requests.md

@@ -1,36 +0,0 @@
----
-title: About required reviews for pull requests
-intro: Required reviews ensure that pull requests have a specific number of approving reviews before collaborators can make changes to a protected branch.
-product: '{% data reusables.gated-features.protected-branches %}'
-redirect_from:
-  - /articles/about-required-reviews-for-pull-requests
-versions:
-  free-pro-team: '*'
-  enterprise-server: '*'
-  github-ae: '*'
----
-
-If you've enforced branch protections in your repository, you can set up required reviews. For more information about enforcing branch protections, see "[Configuring protected branches](/articles/configuring-protected-branches/)." For more information about setting up required reviews, see "[Enabling required reviews for pull requests](/articles/enabling-required-reviews-for-pull-requests)."
-
-{% data reusables.pull_requests.required-reviews-for-prs-summary %}
-
-If a person with *admin* permissions chooses the **Request changes** option in a review, then that person must approve the pull request before it can be merged. If a reviewer who requests changes on a pull request isn't available, anyone with *admin* or *write* permission for the repository can dismiss the blocking review. For more information, see "[Dismissing a pull request review](/articles/dismissing-a-pull-request-review)."
-
-{% note %}
-
-**Note:** Repository admins can restrict the ability to dismiss pull request reviews to specific people or teams. For more information, see "[Enabling required reviews for pull requests](/articles/enabling-required-reviews-for-pull-requests)."
-
-{% endnote %}
-
-If you push a code-modifying commit to the branch of an approved pull request, the approval may be dismissed if repository admins have set up stale review dismissals. For more information, see "[Enabling required reviews for pull requests](/articles/enabling-required-reviews-for-pull-requests)." This doesn't apply if you push non-code-modifying commits, like merging the base branch into your pull request's branch. For information about the base branch, see "[About pull requests](/articles/about-pull-requests)."
-
-Unless required reviews have been set up to include repository admins, people with *admin* permissions can merge a pull request regardless of reviews from other admins.
-
-{% data reusables.repositories.review-policy-overlapping-commits %}
-
-You can't merge a pull request into a protected branch until someone with *write* or *admin* permissions approves it. If there are pending or rejected reviews, you'll receive an error message:
-
-```shell
-remote: error: GH006: Protected branch update failed for refs/heads/main.
-remote: error: Changes have been requested.
-```

content/github/administering-a-repository/about-required-status-checks.md

@@ -1,72 +0,0 @@
----
-title: About required status checks
-intro: Required status checks ensure that all required CI tests are passing before collaborators can make changes to a protected branch.
-product: '{% data reusables.gated-features.protected-branches %}'
-redirect_from:
-  - /articles/about-required-status-checks
-versions:
-  free-pro-team: '*'
-  enterprise-server: '*'
-  github-ae: '*'
----
-
-### About required status checks
-
-If you've enforced branch protections in your repository, you can set up required status checks. For more information, see "[Configuring protected branches](/articles/configuring-protected-branches/)" and "[Enabling required status checks](/articles/enabling-required-status-checks)." Required status checks can be checks or statuses. For more information, see "[About status checks](/github/administering-a-repository/enabling-required-status-checks)."
-
-After enabling required status checks, all required status checks must pass before branches can be merged into the protected branch. After all required status checks pass, any commits must either be pushed to another branch and then merged or pushed directly to the protected branch.  
-
-![Merge protected branch ](/assets/images/help/repository/req-status-check-all-passed.png)
-
-{% tip %}
-
-**Note:** Any person or integration with write permissions to a repository can set the state of any status check in the repository. {% data variables.product.product_name %} does not verify that the author of a check is authorized to create a check with a certain name or modify an existing status. Before merging a pull request, you should verify that the author of each status, listed in the merge box, is expected.
-
-{% endtip %}
-
-Administrators of a repository can merge a protected branch even if required status checks have failed or are pending. You can require administrators to be subject to required status checks. For more information, see "[Enabling required status checks](/github/administering-a-repository/enabling-required-status-checks)."
-
-![Administrator merge of protected branch](/assets/images/help/repository/req-status-check-admin-merge.png)
-
-Administrators can also merge a protected branch even if the branch is out of date with the base branch.
-
-### Required status checks settings
-
-You can set up either loose or strict status checks, depending on whether you want to require your branch to be up to date with the base branch before merging. For more information, see "[Types of required status checks](/github/administering-a-repository/types-of-required-status-checks)."
-
-### Troubleshooting required status checks
-
-If you have a check and a status with the same name and you select that name as a required status check, both the check and the status are required. For more information, see "[Checks](/rest/reference/checks)."
-
-Once you've set up required status checks, your branch must be up to date with the base branch before merging. This ensures that your branch has been tested with the latest code from the base branch. If your branch is out of date, you'll need to merge the base branch into your branch.  
-
-{% note %}
-
-**Note:** You can also bring your branch up to date with the base branch using Git rebase. For more information, see "[About Git rebase](/github/using-git/about-git-rebase)."
-
-{% endnote %}
-
-![Out-of-date branch](/assets/images/help/repository/req-status-check-out-of-date.png)
-
-You won't be able to push local changes to a protected branch until all required status checks pass. Instead, you'll receive an error message similar to the following:
-
-```shell
-remote: error: GH006: Protected branch update failed for refs/heads/main.
-remote: error: Required status check "ci-build" is failing
-```
-{% note %}
-
-**Note:** Pull requests that are up to date and pass required status checks can be merged locally and pushed to the protected branch. This can be done without status checks running on the merge commit itself.
-
-{% endnote %}
-
-{% if currentVersion == "free-pro-team@latest" or currentVersion == "github-ae@latest" or currentVersion ver_gt "enterprise-server@2.20" %}
-
-Sometimes, the results of the status checks for the test merge commit and head commit will conflict. If the test merge commit has a status, it must pass. Otherwise, the status of the head commit must pass before you can merge the branch. For more information about test merge commits, see "[Pull Requests](/rest/reference/pulls#response-1)."
-
-![Branch with conflicting merge commits](/assets/images/help/repository/req-status-check-conflicting-merge-commits.png)
-{% endif %}
-
-### Further reading
-
-- "[About status checks](/github/collaborating-with-issues-and-pull-requests/about-status-checks)"

content/github/administering-a-repository/configuring-protected-branches.md

@@ -1,42 +0,0 @@
----
-title: Configuring protected branches
-intro: 'If you''re a repository owner or have admin permissions in a repository, you can customize branch protections in the repository and enforce certain workflows, such as requiring more than one pull request review or requiring certain status checks to pass before allowing a pull request to merge.'
-product: '{% data reusables.gated-features.protected-branches %}'
-redirect_from:
-  - /articles/configuring-protected-branches
-  - /enterprise/admin/developer-workflow/configuring-protected-branches-and-required-status-checks
-versions:
-  free-pro-team: '*'
-  enterprise-server: '*'
-  github-ae: '*'
----
-
-
-{% data reusables.repositories.branch-rules-example %}
-
-You can also set up automatic branch protection for all branches in your repository with the wildcard syntax `*`. Because {% data variables.product.prodname_dotcom %} uses the `File::FNM_PATHNAME` flag for the `File.fnmatch` syntax, the wildcard does not match directory separators (`/`). For example, `qa/*` will match all branches beginning with `qa/` and containing a single slash. You can include multiple slashes with `qa/**/*`, and you can extend the `qa` string with `qa**/**/*` to make it more inclusive. For more information about syntax options for branch rules, see the [fnmatch documentation](https://ruby-doc.org/core-2.5.1/File.html#method-c-fnmatch).
-
-To create an exception to an existing branch rule, you can create a new branch protection rule that is higher priority, such as a branch rule for a specific branch name. For more information about the priority order and other settings for protected branch rules, see "[About protected branches](/github/administering-a-repository/about-protected-branches)."
-
-{% note %}
-
-**Note:** To create a branch rule, the branch you specify doesn't have to exist yet in the repository.
-
-{% endnote %}
-
-{% data reusables.repositories.navigate-to-repo %}
-{% data reusables.repositories.sidebar-settings %}
-{% data reusables.repositories.repository-branches %}
-{% data reusables.repositories.add-branch-protection-rules %}
-6. Optionally, you can configure specific branch rule settings.
-![Protected branch rule settings](/assets/images/help/branches/branch-rule-settings.png)
-7. To confirm your branch protection rule, click **Create** or **Save changes.**
-
-### Further reading
-
-- "[About protected branches](/github/administering-a-repository/about-protected-branches)"
-- "[About required status checks](/github/administering-a-repository/about-required-status-checks)"
-- "[Enabling required status checks](/github/administering-a-repository/enabling-required-status-checks)"
-- "[About branch restrictions](/github/administering-a-repository/about-branch-restrictions)"
-- "[Enabling branch restrictions](/github/administering-a-repository/enabling-branch-restrictions)"
-- "[About required commit signing](/github/administering-a-repository/about-required-commit-signing)"

content/github/administering-a-repository/enabling-branch-restrictions.md

@@ -1,33 +0,0 @@
----
-title: Enabling branch restrictions
-intro: 'You can enforce branch restrictions so that only certain users, teams, or apps can push to a protected branch in repositories owned by your organization.'
-product: '{% data reusables.gated-features.branch-restrictions %}'
-redirect_from:
-  - /articles/enabling-branch-restrictions
-versions:
-  free-pro-team: '*'
-  enterprise-server: '*'
-  github-ae: '*'
----
-
-Anyone with admin permissions to an organization-owned repository can enable branch restrictions.
-
-{% data reusables.repositories.protected-branches-options %}
-
-{% data reusables.repositories.navigate-to-repo %}
-{% data reusables.repositories.sidebar-settings %}
-{% data reusables.repositories.repository-branches %}
-{% data reusables.repositories.add-branch-protection-rules %}
-{% data reusables.repositories.include-administrators %}
-6. Under "Protect matching branches", select **Restrict who can push to matching branches**.
-![Branch restriction checkbox](/assets/images/help/repository/restrict-branch.png)
-8. Search for and select the people, teams, or apps who will have permission to push to the protected branch.
-![Branch restriction search](/assets/images/help/repository/restrict-branch-search.png)
-9. Click **Create**.
-
-### Further reading
-
-- "[About protected branches](/github/administering-a-repository/about-protected-branches)"
-- "[Configuring protected branches](/github/administering-a-repository/configuring-protected-branches)"
-- "[About required status checks](/github/administering-a-repository/about-required-status-checks)"
-- "[Enabling required status checks](/github/administering-a-repository/enabling-required-status-checks)"

content/github/administering-a-repository/enabling-deletion-of-a-protected-branch.md

@@ -1,23 +0,0 @@
----
-title: Enabling deletion of a protected branch
-intro: You can allow anyone with write access for a repository to delete a protected branch.
-product: '{% data reusables.gated-features.protected-branches %}'
-versions:
-  free-pro-team: '*'
-  enterprise-server: '>=2.20'
-  github-ae: '*'
----
-
-Anyone with admin permissions to a repository can enable branch deletions.
-
-By default, you cannot delete a protected branch. When you enable deletion to a protected branch, anyone with at least write permissions to the repository can delete the branch, including those with admin permissions.
-
-{% data reusables.repositories.protected-branches-options %}
-
-{% data reusables.repositories.navigate-to-repo %}
-{% data reusables.repositories.sidebar-settings %}
-{% data reusables.repositories.repository-branches %}
-{% data reusables.repositories.add-branch-protection-rules %}
-6. Under "Rules applied to everyone including administrators", select **Allow deletions**.
-![Allow branch deletions option](/assets/images/help/repository/allow-branch-deletions.png)
-7. Click **Create**.

content/github/administering-a-repository/enabling-force-pushes-to-a-protected-branch.md

@@ -1,33 +0,0 @@
----
-title: Enabling force pushes to a protected branch
-intro: You can allow force pushes to a protected branch.
-product: '{% data reusables.gated-features.protected-branches %}'
-versions:
-  free-pro-team: '*'
-  enterprise-server: '>=2.20'
-  github-ae: '*'
----
-
-Anyone with admin permissions to a repository can enable force pushes.
-
-### About force pushes to protected branches
-
-By default, force pushes are blocked on all protected branches. When you enable force pushes to a protected branch, anyone with at least write permissions to the repository can force push to the branch, including those with admin permissions.
-
-Enabling force pushes will not override any other branch protection rules. For example, if a branch requires a linear commit history, you cannot force push merge commits to that branch.
-
-{% if enterpriseServerVersions contains currentVersion or currentVersion == "github-ae@latest" %}You cannot enable force pushes for a protected branch if a site administrator has blocked force pushes to all branches in your repository. For more information, see "[Blocking force pushes to repositories owned by a user account or organization](/enterprise/{{ currentVersion }}/admin/developer-workflow/blocking-force-pushes-to-repositories-owned-by-a-user-account-or-organization)."
-
-If a site administrator has blocked force pushes to the default branch only, you can still enable force pushes for any other protected branch.{% endif %}
-
-{% data reusables.repositories.protected-branches-options %}
-
-### Enabling force pushes
-
-{% data reusables.repositories.navigate-to-repo %}
-{% data reusables.repositories.sidebar-settings %}
-{% data reusables.repositories.repository-branches %}
-{% data reusables.repositories.add-branch-protection-rules %}
-6. Under "Rules applied to everyone including administrators", select **Allow force pushes**.
-![Allow force pushes option](/assets/images/help/repository/allow-force-pushes.png)
-7. Click **Create**.

content/github/administering-a-repository/enabling-required-commit-signing.md

@@ -1,25 +0,0 @@
----
-title: Enabling required commit signing
-intro: Repository administrators can enforce required commit signing on a branch to block all commits that are not signed and verified.
-product: '{% data reusables.gated-features.protected-branches %}'
-redirect_from:
-  - /articles/enabling-required-commit-signing
-versions:
-  free-pro-team: '*'
-  enterprise-server: '*'
-  github-ae: '*'
----
-
-Before enabling required commit signing on a branch, you must first set the branch up as a protected branch. For more information, see "[Configuring protected branches](/github/administering-a-repository/configuring-protected-branches)."
-
-{% data reusables.repositories.protected-branches-options %}
-
-{% data reusables.repositories.navigate-to-repo %}
-{% data reusables.repositories.sidebar-settings %}
-{% data reusables.repositories.repository-branches %}
-{% data reusables.repositories.add-branch-protection-rules %}
-5. Select **Require signed commits**.
-![Require signed commits option](/assets/images/help/repository/require-signed-commits.png)
-6. Optionally, select **Include administrators**. This enforces the required signed commits on the repository administrators.
-![Include administrators checkbox](/assets/images/help/repository/include-admins-protected-branches.png)
-7. Click **Create**.

content/github/administering-a-repository/enabling-required-reviews-for-pull-requests.md

@@ -1,38 +0,0 @@
----
-title: Enabling required reviews for pull requests
-intro: Repository administrators can enforce required reviews so that pull requests must have a specific number of approving reviews before they are merged.
-product: '{% data reusables.gated-features.protected-branches %}'
-redirect_from:
-  - /articles/enabling-required-reviews-for-pull-requests
-versions:
-  free-pro-team: '*'
-  enterprise-server: '*'
-  github-ae: '*'
----
-
-Before enabling required reviews on a branch, you must first set the branch up as a protected branch. For more information, see "[Configuring protected branches](/github/administering-a-repository/configuring-protected-branches)."
-
-{% data reusables.repositories.protected-branches-options %}
-
-{% data reusables.repositories.navigate-to-repo %}
-{% data reusables.repositories.sidebar-settings %}
-{% data reusables.repositories.repository-branches %}
-{% data reusables.repositories.add-branch-protection-rules %}
-5. Select **Require pull request reviews before merging**.
-![Pull request review restriction checkbox](/assets/images/help/repository/PR-reviews-required.png)
-6. In the Required approving reviews drop-down menu, select the number of approving reviews you'd like to require on the branch.
-![Drop-down menu to select number of required review approvals](/assets/images/help/repository/number-of-required-review-approvals.png)
-7. Optionally, select **Dismiss stale pull request approvals when new commits are pushed**. This dismisses a pull request approval review when a code-modifying commit is pushed to the branch.
-![Dismiss stale pull request approvals when new commits are pushed checkbox](/assets/images/help/repository/PR-reviews-required-dismiss-stale.png)
-8. Optionally, select **Require review from Code Owners** to require review from a code owner when the pull request affects code that has a designated owner. For more information, see "[About code owners](/github/creating-cloning-and-archiving-repositories/about-code-owners)."
-![Require review from code owners](/assets/images/help/repository/PR-review-required-code-owner.png)
-9. Optionally, if the repository is part of an organization, select **Restrict who can dismiss pull request reviews** to search for and select the people or teams who can dismiss pull request reviews. For more information, see "[Dismissing a pull request review](/github/collaborating-with-issues-and-pull-requests/dismissing-a-pull-request-review)." This option is not available for personal repositories.
-![Restrict who can dismiss pull request reviews checkbox](/assets/images/help/repository/PR-review-required-dismissals.png)
-{% data reusables.repositories.include-administrators %}
-11. Click **Create**.
-
-### Further reading
-
-- "[About required reviews for pull requests](/github/administering-a-repository/about-required-reviews-for-pull-requests)"
-- "[About protected branches](/github/administering-a-repository/about-protected-branches)"
-- "[About required status checks](/github/administering-a-repository/about-required-status-checks)"

content/github/administering-a-repository/enabling-required-status-checks.md

@@ -1,30 +0,0 @@
----
-title: Enabling required status checks
-intro: Repository administrators can enforce required status checks before a branch is merged in a pull request or before commits on a local branch can be pushed to the protected remote branch.
-product: '{% data reusables.gated-features.protected-branches %}'
-redirect_from:
-  - /articles/enabling-required-status-checks
-versions:
-  free-pro-team: '*'
-  enterprise-server: '*'
-  github-ae: '*'
----
-
-{% data reusables.repositories.protected-branches-options %}
-
-Before you can enable required status checks, you must configure the repository to use the status API. For more information, see "[Building a CI Server](/guides/building-a-ci-server/)."
-
-{% data reusables.repositories.navigate-to-repo %}
-{% data reusables.repositories.sidebar-settings %}
-{% data reusables.repositories.repository-branches %}
-{% data reusables.repositories.add-branch-protection-rules %}
-6. Under "Protect matching branches", select **Require status checks to pass before merging**.
-![Required status checks option](/assets/images/help/repository/required-status-checks.png)
-7. Optionally, select **Require branches to be up to date before merging**. If selected, this ensures that the branch is tested with the latest code on the base branch.
-![Loose or strict required status checkbox](/assets/images/help/repository/protecting-branch-loose-status.png)
-7. From the list of available status checks, select the checks you want to require.
-![List of available status checks](/assets/images/help/repository/required-statuses-list.png)
-{% data reusables.repositories.include-administrators %}
-9. Click **Create**.
-
-{% data reusables.repositories.required-status-merge-tip %}

content/github/administering-a-repository/index.md

@@ -44,19 +44,8 @@ versions:
     {% link_in_list /managing-the-automatic-deletion-of-branches %}
 {% topic_link_in_list /defining-the-mergeability-of-pull-requests %}
     {% link_in_list /about-protected-branches %}
-    {% link_in_list /configuring-protected-branches %}
-    {% link_in_list /about-required-status-checks %}
-    {% link_in_list /types-of-required-status-checks %}
-    {% link_in_list /enabling-required-status-checks %}
-    {% link_in_list /about-branch-restrictions %}
-    {% link_in_list /enabling-branch-restrictions %}
-    {% link_in_list /about-required-reviews-for-pull-requests %}
-    {% link_in_list /enabling-required-reviews-for-pull-requests %}
-    {% link_in_list /about-required-commit-signing %}
-    {% link_in_list /enabling-required-commit-signing %}
-    {% link_in_list /requiring-a-linear-commit-history %}
-    {% link_in_list /enabling-force-pushes-to-a-protected-branch %}
-    {% link_in_list /enabling-deletion-of-a-protected-branch %}
+    {% link_in_list /managing-a-branch-protection-rule %}
+    {% link_in_list /troubleshooting-required-status-checks %}
 {% topic_link_in_list /releasing-projects-on-github %}
     {% link_in_list /about-releases %}
     {% link_in_list /managing-releases-in-a-repository %}

content/github/administering-a-repository/managing-a-branch-protection-rule.md

@@ -0,0 +1,100 @@
+---
+title: Managing a branch protection rule
+intro: 'You can create a branch protection rule to enforce certain workflows for one or more branches, such as requiring an approving review or passing status checks for all pull requests merged into the protected branch.'
+product: '{% data reusables.gated-features.protected-branches %}'
+redirect_from:
+  - /articles/configuring-protected-branches
+  - /enterprise/admin/developer-workflow/configuring-protected-branches-and-required-status-checks
+  - /articles/enabling-required-status-checks
+  - /github/administering-a-repository/enabling-required-status-checks
+  - /articles/enabling-branch-restrictions
+  - /github/administering-a-repository/enabling-branch-restrictions
+  - /articles/enabling-required-reviews-for-pull-requests
+  - /github/administering-a-repository/enabling-required-reviews-for-pull-requests
+  - /articles/enabling-required-commit-signing
+  - /github/administering-a-repository/enabling-required-commit-signing
+  - /github/administering-a-repository/requiring-a-linear-commit-history
+  - /github/administering-a-repository/enabling-force-pushes-to-a-protected-branch
+  - /github/administering-a-repository/enabling-deletion-of-a-protected-branch
+versions:
+  free-pro-team: '*'
+  enterprise-server: '*'
+  github-ae: '*'
+permissions: People with admin permissions to a repository can manage branch protection rules.
+---
+
+### About branch protection rules
+
+{% data reusables.repositories.branch-rules-example %}
+
+You can create a rule for all current and future branches in your repository with the wildcard syntax `*`. Because {% data variables.product.company_short %} uses the `File::FNM_PATHNAME` flag for the `File.fnmatch` syntax, the wildcard does not match directory separators (`/`). For example, `qa/*` will match all branches beginning with `qa/` and containing a single slash. You can include multiple slashes with `qa/**/*`, and you can extend the `qa` string with `qa**/**/*` to make the rule more inclusive. For more information about syntax options for branch rules, see the [fnmatch documentation](https://ruby-doc.org/core-2.5.1/File.html#method-c-fnmatch).
+
+If a repository has multiple protected branch rules that affect the same branches, the rules that include a specific branch name have the highest priority. If there is more than one protected branch rule that references the same specific branch name, then the branch rule created first will have higher priority.
+
+Protected branch rules that mention a special character, such as `*`, `?`, or `]`, are applied in the order they were created, so older rules with these characters have a higher priority.
+
+To create an exception to an existing branch rule, you can create a new branch protection rule that is higher priority, such as a branch rule for a specific branch name. 
+
+For more information about each of each of the available branch protection settings, see "[About protected branches](/github/administering-a-repository/about-protected-branches)."
+
+### Creating a branch protection rule
+
+When you create a branch rule, the branch you specify doesn't have to exist yet in the repository.
+
+{% data reusables.repositories.navigate-to-repo %}
+{% data reusables.repositories.sidebar-settings %}
+{% data reusables.repositories.repository-branches %}
+{% data reusables.repositories.add-branch-protection-rules %}
+1. Optionally, enable required pull request reviews.
+   - Under "Protect matching branches", select **Require pull request reviews before merging**.
+     ![Pull request review restriction checkbox](/assets/images/help/repository/PR-reviews-required.png)
+   - Click the **Required approving reviews** drop-down menu, then select the number of approving reviews you'd like to require on the branch.
+     ![Drop-down menu to select number of required review approvals](/assets/images/help/repository/number-of-required-review-approvals.png)
+   - Optionally, to dismiss a pull request approval review when a code-modifying commit is pushed to the branch, select **Dismiss stale pull request approvals when new commits are pushed**.
+     ![Dismiss stale pull request approvals when new commits are pushed checkbox](/assets/images/help/repository/PR-reviews-required-dismiss-stale.png)
+   - Optionally, to require review from a code owner when the pull request affects code that has a designated owner, select **Require review from Code Owners**. For more information, see "[About code owners](/github/creating-cloning-and-archiving-repositories/about-code-owners)."
+     ![Require review from code owners](/assets/images/help/repository/PR-review-required-code-owner.png)
+   - Optionally, if the repository is part of an organization, select **Restrict who can dismiss pull request reviews**. Then, search for and select the people or teams who are allowed to dismiss pull request reviews. For more information, see "[Dismissing a pull request review](/github/collaborating-with-issues-and-pull-requests/dismissing-a-pull-request-review)."
+     ![Restrict who can dismiss pull request reviews checkbox](/assets/images/help/repository/PR-review-required-dismissals.png)
+1. Optionally, enable required status checks.
+   - Select **Require status checks to pass before merging**.
+     ![Required status checks option](/assets/images/help/repository/required-status-checks.png)
+   - Optionally, to ensure that pull requests are tested with the latest code on the protected branch, select **Require branches to be up to date before merging**.
+     ![Loose or strict required status checkbox](/assets/images/help/repository/protecting-branch-loose-status.png)
+   - From the list of available status checks, select the checks you want to require.
+     ![List of available status checks](/assets/images/help/repository/required-statuses-list.png)
+1. Optionally, select **Require signed commits**.
+  ![Require signed commits option](/assets/images/help/repository/require-signed-commits.png)
+1. Optionally, select **Require linear history**.
+  ![Required linear history option](/assets/images/help/repository/required-linear-history.png)
+1. Optionally, select **Include administrators**.
+![Include administrators checkbox](/assets/images/help/repository/include-admins-protected-branches.png)
+1. Optionally,{% if currentVersion == "free-pro-team@latest" %} if your repository is owned by an organization using {% data variables.product.prodname_team %} or {% data variables.product.prodname_ghe_cloud %},{% endif %} enable branch restrictions.
+   - Select **Restrict who can push to matching branches**.
+     ![Branch restriction checkbox](/assets/images/help/repository/restrict-branch.png)
+   - Search for and select the people, teams, or apps who will have permission to push to the protected branch.
+     ![Branch restriction search](/assets/images/help/repository/restrict-branch-search.png)
+1. Optionally, under "Rules applied to everyone including administrators", select **Allow force pushes**.
+  ![Allow force pushes option](/assets/images/help/repository/allow-force-pushes.png)
+1. Optionally, select **Allow deletions**.
+  ![Allow branch deletions option](/assets/images/help/repository/allow-branch-deletions.png)
+1. Click **Create**.
+
+### Editing a branch protection rule
+
+{% data reusables.repositories.navigate-to-repo %}
+{% data reusables.repositories.sidebar-settings %}
+{% data reusables.repositories.repository-branches %}
+1. To the right of the branch protection rule you want to edit, click **Edit**.
+  ![Edit button](/assets/images/help/repository/edit-branch-protection-rule.png)
+1. Make your desired changes to the branch protection rule.
+1. Click **Save changes**.
+  ![Save changes button](/assets/images/help/repository/save-branch-protection-rule.png)
+
+### Deleting a branch protection rule
+
+{% data reusables.repositories.navigate-to-repo %}
+{% data reusables.repositories.sidebar-settings %}
+{% data reusables.repositories.repository-branches %}
+1. To the right of the branch protection rule you want to delete, click **Delete**.
+    ![Delete button](/assets/images/help/repository/delete-branch-protection-rule.png)

content/github/administering-a-repository/requiring-a-linear-commit-history.md

@@ -1,31 +0,0 @@
----
-title: Requiring a linear commit history
-intro: You can require a linear commit history to block all merge commits from a protected branch.
-product: '{% data reusables.gated-features.protected-branches %}'
-versions:
-  free-pro-team: '*'
-  enterprise-server: '>=2.20'
-  github-ae: '*'
----
-
-Anyone with admin permissions to a repository can require a linear commit history.
-
-### About enforcement of linear commit history
-
-Enforcing a linear commit history prevents merge commits from being pushed to the protected branch. This means that any pull requests merged into the protected branch must use a squash merge or a rebase merge. A strictly linear commit history can help teams backtrack changes more efficiently. For more information about merge methods, see "[About pull request merges](/github/collaborating-with-issues-and-pull-requests/about-pull-request-merges)."
-
-{% data reusables.repositories.protected-branches-options %}
-
-Before you can require a linear commit history, your repository must allow squash merging or rebase merging. For more information, see "[Configuring pull request merges](/github/administering-a-repository/configuring-pull-request-merges)."
-
-
-### Enforcing a linear commit history
-
-{% data reusables.repositories.navigate-to-repo %}
-{% data reusables.repositories.sidebar-settings %}
-{% data reusables.repositories.repository-branches %}
-{% data reusables.repositories.add-branch-protection-rules %}
-6. Under "Protect matching branches", select **Require linear history**.
-![Required linear history option](/assets/images/help/repository/required-linear-history.png)
-{% data reusables.repositories.include-administrators %}
-7. Click **Create**.

content/github/administering-a-repository/troubleshooting-required-status-checks.md

@@ -0,0 +1,38 @@
+---
+title: Troubleshooting required status checks
+intro: 'You can check for common errors and resolve issues with required status checks.'
+product: '{% data reusables.gated-features.protected-branches %}'
+versions:
+  free-pro-team: '*'
+  enterprise-server: '*'
+  github-ae: '*'
+---
+
+If you have a check and a status with the same name, and you select that name as a required status check, both the check and the status are required. For more information, see "[Checks](/rest/reference/checks)."
+
+After you enable required status checks, your branch may need to be up-to-date with the base branch before merging. This ensures that your branch has been tested with the latest code from the base branch. If your branch is out of date, you'll need to merge the base branch into your branch. For more information, see "[About protected branches](/github/administering-a-repository/about-protected-branches#require-status-checks-before-merging)."
+
+{% note %}
+
+**Note:** You can also bring your branch up to date with the base branch using Git rebase. For more information, see "[About Git rebase](/github/using-git/about-git-rebase)."
+
+{% endnote %}
+
+You won't be able to push local changes to a protected branch until all required status checks pass. Instead, you'll receive an error message similar to the following.
+
+```shell
+remote: error: GH006: Protected branch update failed for refs/heads/main.
+remote: error: Required status check "ci-build" is failing
+```
+{% note %}
+
+**Note:** Pull requests that are up-to-date and pass required status checks can be merged locally and pushed to the protected branch. This can be done without status checks running on the merge commit itself.
+
+{% endnote %}
+
+{% if currentVersion == "free-pro-team@latest" or currentVersion == "github-ae@latest" or currentVersion ver_gt "enterprise-server@2.20" %}
+
+Sometimes, the results of the status checks for the test merge commit and head commit will conflict. If the test merge commit has a status, the test merge commit must pass. Otherwise, the status of the head commit must pass before you can merge the branch. For more information about test merge commits, see "[Pulls](/rest/reference/pulls#get-a-pull-request)."
+
+![Branch with conflicting merge commits](/assets/images/help/repository/req-status-check-conflicting-merge-commits.png)
+{% endif %}

content/github/administering-a-repository/types-of-required-status-checks.md

@@ -1,22 +0,0 @@
----
-title: Types of required status checks
-intro: You can set up required status checks to either be "loose" or "strict." The type of required status check you choose determines whether your branch is required to be up to date with the base branch before merging.
-product: '{% data reusables.gated-features.protected-branches %}'
-redirect_from:
-  - /articles/types-of-required-status-checks
-versions:
-  free-pro-team: '*'
-  enterprise-server: '*'
-  github-ae: '*'
----
-
-| Type of required status check | Setting | Merge requirements | Considerations |
-| --- | --- | --- | --- |
-| **Strict** | The **Require branches to be up-to-date before merging** checkbox is checked. | The branch **must** be up to date with the base branch before merging. | This is the default behavior for required status checks. More builds may be required, as you'll need to bring the head branch up to date after other collaborators merge pull requests to the protected base branch.|
-| **Loose** | The **Require branches to be up-to-date before merging** checkbox is **not** checked. | The branch **does not** have to be up to date with the base branch before merging. | You'll have fewer required builds, as you won't need to bring the head branch up to date after other collaborators merge pull requests. Status checks may fail after you merge your branch if there are incompatible changes with the base branch. |
-| **Disabled** | The **Require status checks to pass before merging** checkbox is **not** checked. | The branch has no merge restrictions. | If required status checks aren't enabled, collaborators can merge the branch at any time, regardless of whether it is up to date with the base branch. This increases the possibility of incompatible changes.
-
-### Further reading
-
-- "[About required status checks](/articles/about-required-status-checks)"
-- "[Enabling required status checks](/articles/enabling-required-status-checks)"

content/github/authenticating-to-github/about-commit-signature-verification.md

@@ -19,7 +19,7 @@ You can sign commits and tags locally, so other people can verify that your work
 
 If a commit or tag has a signature that cannot be verified, {% data variables.product.product_name %} marks the commit or tag as unverified.
 
-Repository administrators can enforce required commit signing on a branch to block all commits that are not signed and verified. For more information, see "[About required commit signing](/articles/about-required-commit-signing)."
+Repository administrators can enforce required commit signing on a branch to block all commits that are not signed and verified. For more information, see "[About protected branches](/github/administering-a-repository/about-protected-branches#require-signed-commits)."
 
 You can check the verification status of your signed commits or tags on {% data variables.product.product_name %} and view why your commit signatures might be unverified. For more information, see "[Checking your commit and tag signature verification status](/articles/checking-your-commit-and-tag-signature-verification-status)."
 

content/github/collaborating-with-issues-and-pull-requests/about-branches.md

@@ -74,7 +74,7 @@ When a branch is protected:
 - If required status checks are enabled on the branch, you won't be able to merge changes into the branch until all of the required CI tests pass. For more information, see "[About status checks](/articles/about-status-checks)."
 - If required pull request reviews are enabled on the branch, you won't be able to merge changes into the branch until all requirements in the pull request review policy have been met. For more information, see "[Merging a pull request](/articles/merging-a-pull-request)."
 - If required review from a code owner is enabled on a branch, and a pull request modifies code that has an owner, a code owner must approve the pull request before it can be merged. For more information, see "[About code owners](/articles/about-code-owners)."
-- If required commit signing is enabled on a branch, you won't be able to push any commits to the branch that are not signed and verified. For more information, see "[About commit signature verification](/articles/about-commit-signature-verification)" and "[About required commit signing](/articles/about-required-commit-signing)."{% if currentVersion == "free-pro-team@latest" or currentVersion == "github-ae@latest" or currentVersion ver_gt "enterprise-server@2.21" %}
+- If required commit signing is enabled on a branch, you won't be able to push any commits to the branch that are not signed and verified. For more information, see "[About commit signature verification](/articles/about-commit-signature-verification)" and "[About protected branches](/github/administering-a-repository/about-protected-branches#require-signed-commits)."{% if currentVersion == "free-pro-team@latest" or currentVersion == "github-ae@latest" or currentVersion ver_gt "enterprise-server@2.21" %}
 - If you use {% data variables.product.prodname_dotcom %}'s conflict editor to fix conflicts for a pull request that you created from a protected branch, {% data variables.product.prodname_dotcom %}  helps you to create an alternative branch for the pull request, so that your resolution of the conflicts can be merged. For more information, see "[Resolving a merge conflict on {% data variables.product.prodname_dotcom %}](/github/collaborating-with-issues-and-pull-requests/resolving-a-merge-conflict-on-github)."{% endif %}
 
 ### Further reading

content/github/collaborating-with-issues-and-pull-requests/about-pull-request-reviews.md

@@ -44,9 +44,7 @@ You can view all of the reviews a pull request has received in the Conversation
 
 ### Required reviews
 
-{% data reusables.pull_requests.required-reviews-for-prs-summary %}
-
-For more information, see "[About required reviews for pull requests](/articles/about-required-reviews-for-pull-requests)."
+{% data reusables.pull_requests.required-reviews-for-prs-summary %} For more information, see "[About protected branches](/github/administering-a-repository/about-protected-branches#require-pull-request-reviews-before-merging)."
 
 {% tip %}
 
@@ -57,6 +55,5 @@ For more information, see "[About required reviews for pull requests](/articles/
 ### Further reading
 
 - "[Reviewing proposed changes in a pull request](/articles/reviewing-proposed-changes-in-a-pull-request)"
-- "[Enabling required reviews for pull requests](/articles/enabling-required-reviews-for-pull-requests)"
 - "[Viewing a pull request review](/articles/viewing-a-pull-request-review)"
 - "[Setting guidelines for repository contributors](/articles/setting-guidelines-for-repository-contributors)"

content/github/collaborating-with-issues-and-pull-requests/approving-a-pull-request-with-required-reviews.md

@@ -9,9 +9,9 @@ versions:
   github-ae: '*'
 ---
 
-For more information about required reviews, see "[About required reviews for pull requests](/articles/about-required-reviews-for-pull-requests)."
+For more information about required reviews, see "[About protected branches](/github/administering-a-repository/about-protected-branches#require-pull-request-reviews-before-merging)."
 
-You can comment on a pull request, approve the changes, or request improvements before approving. For more information, see "[About required reviews for pull requests](/articles/about-required-reviews-for-pull-requests)" and "[Reviewing proposed changes in a pull request](/articles/reviewing-proposed-changes-in-a-pull-request)."
+You can comment on a pull request, approve the changes, or request improvements before approving. For more information, see "[Reviewing proposed changes in a pull request](/articles/reviewing-proposed-changes-in-a-pull-request)."
 
 {% data reusables.search.requested_reviews_search %}
 
@@ -34,6 +34,5 @@ You can comment on a pull request, approve the changes, or request improvements
 
 ### Further reading
 
-- "[About required reviews for pull requests](/articles/about-required-reviews-for-pull-requests)"
 - "[Reviewing proposed changes in a pull request](/articles/reviewing-proposed-changes-in-a-pull-request)"
 - "[Commenting on a pull request](/articles/commenting-on-a-pull-request)"

content/github/collaborating-with-issues-and-pull-requests/committing-changes-to-a-pull-request-branch-created-from-a-fork.md

@@ -13,7 +13,7 @@ You can only make commits on pull request branches that:
 - are opened in a repository that you have push access to and that were created from a fork of that repository
 - are on a user-owned fork
 - have permission granted from the pull request creator
-- don't have [branch restrictions](/articles/about-branch-restrictions) that will prevent you from committing
+- don't have [branch restrictions](/github/administering-a-repository/about-protected-branches#restrict-who-can-push-to-matching-branches) that will prevent you from committing
 
 Only the user who created the pull request can give you permission to push commits to the user-owned fork. For more information, see "[Allowing changes to a pull request branch created from a fork](/articles/allowing-changes-to-a-pull-request-branch-created-from-a-fork)."
 

content/github/collaborating-with-issues-and-pull-requests/dismissing-a-pull-request-review.md

@@ -1,6 +1,6 @@
 ---
 title: Dismissing a pull request review
-intro: 'If your repository [requires reviews](/articles/about-required-reviews-for-pull-requests), you can dismiss pull request reviews that are no longer valid or are unable to be approved by the reviewer.'
+intro: 'If your repository requires reviews, you can dismiss pull request reviews that are no longer valid or are unable to be approved by the reviewer.'
 redirect_from:
   - /articles/dismissing-a-pull-request-review
 versions:
@@ -26,4 +26,4 @@ This changes the status of the review to a review comment. When you dismiss a re
 
 - "[About pull request reviews](/articles/about-pull-request-reviews)"
 - "[Reviewing proposed changes in a pull request](/articles/reviewing-proposed-changes-in-a-pull-request)"
-- "[About required reviews for pull requests](/articles/about-required-reviews-for-pull-requests)"
+- "[About protected branches](/github/administering-a-repository/about-protected-branches#require-pull-request-reviews-before-merging)"

content/github/collaborating-with-issues-and-pull-requests/merging-a-pull-request.md

@@ -12,7 +12,7 @@ versions:
 
 ### About pull request merges
 
-In a pull request, you propose that changes you've made on a head branch should be merged into a base branch. {% data reusables.pull_requests.about-protected-branches %} However, there may be restrictions on when you can merge a pull request into a specific branch. For example, you may only be able to merge a pull request into the default branch if required status checks are passing. For more information, see "[About protected branches](/github/administering-a-repository/about-protected-branches)."
+In a pull request, you propose that changes you've made on a head branch should be merged into a base branch. By default, any pull request can be merged at any time, unless the head branch is in conflict with the base branch. However, there may be restrictions on when you can merge a pull request into a specific branch. For example, you may only be able to merge a pull request into the default branch if required status checks are passing. For more information, see "[About protected branches](/github/administering-a-repository/about-protected-branches)."
 
 {% data reusables.pull_requests.you-can-auto-merge %}
 

content/github/collaborating-with-issues-and-pull-requests/reviewing-proposed-changes-in-a-pull-request.md

@@ -70,5 +70,5 @@ After you've finished reviewing all the files you want in the pull request, subm
 
 ### Further reading
 
-- "[About required reviews for pull requests](/github/administering-a-repository/about-required-reviews-for-pull-requests)"
+- "[About protected branches](/github/administering-a-repository/about-protected-branches#require-pull-request-reviews-before-merging)"
 - "[Filtering pull requests by review status](/github/managing-your-work-on-github/filtering-pull-requests-by-review-status)"

content/github/creating-cloning-and-archiving-repositories/about-code-owners.md

@@ -19,7 +19,7 @@ The people you choose as code owners must have write permissions for the reposit
 
 Code owners are automatically requested for review when someone opens a pull request that modifies code that they own. Code owners are not automatically requested to review draft pull requests. For more information about draft pull requests, see "[About pull requests](/github/collaborating-with-issues-and-pull-requests/about-pull-requests#draft-pull-requests)." When you mark a draft pull request as ready for review, code owners are automatically notified. If you convert a pull request to a draft, people who are already subscribed to notifications are not automatically unsubscribed. For more information, see "[Changing the stage of a pull request](/github/collaborating-with-issues-and-pull-requests/changing-the-stage-of-a-pull-request)."
 
-When someone with admin or owner permissions has enabled required reviews, they also can optionally require approval from a code owner before the author can merge a pull request in the repository. For more information, see "[Enabling required reviews for pull requests](/github/administering-a-repository/enabling-required-reviews-for-pull-requests)."
+When someone with admin or owner permissions has enabled required reviews, they also can optionally require approval from a code owner before the author can merge a pull request in the repository. For more information, see "[About protected branches](/github/administering-a-repository/about-protected-branches#require-pull-request-reviews-before-merging)."
 
 {% if currentVersion == "free-pro-team@latest" or currentVersion == "github-ae@latest" or currentVersion ver_gt "enterprise-server@2.19" %}If a team has enabled code review assignments, the individual approvals won't satisfy the requirement for code owner approval in a protected branch. For more information, see "[Managing code review assignment for your team](/github/setting-up-and-managing-organizations-and-teams/managing-code-review-assignment-for-your-team)."{% endif %}
 

content/github/creating-cloning-and-archiving-repositories/about-repositories.md

@@ -22,8 +22,8 @@ Each person and organization can own unlimited repositories and invite an unlimi
 {% endif %}
 
 You can use repositories to manage your work and collaborate with others.
-- You can use issues to collect user feedback, report software bugs, and organize tasks you'd like to accomplish. For more information, see "[About issues](/github/managing-your-work-on-github/about-issues)."
-- {% data reusables.discussions.you-can-use-discussions %}
+- You can use issues to collect user feedback, report software bugs, and organize tasks you'd like to accomplish. For more information, see "[About issues](/github/managing-your-work-on-github/about-issues)."{% if currentVersion == "free-pro-team@latest" %}
+- {% data reusables.discussions.you-can-use-discussions %}{% endif %}
 - You can use pull requests to propose changes to a repository. For more information, see "[About pull requests](/github/collaborating-with-issues-and-pull-requests/about-pull-requests)."
 - You can use project boards to organize and prioritize your issues and pull requests. For more information, see "[About project boards](/github/managing-your-work-on-github/about-project-boards)."
 

content/github/finding-security-vulnerabilities-and-errors-in-your-code/triaging-code-scanning-alerts-in-pull-requests.md

@@ -15,7 +15,7 @@ versions:
 
 In repositories where {% data variables.product.prodname_code_scanning %} is configured as a pull request check, {% data variables.product.prodname_code_scanning %} checks the code in the pull request. By default, this is limited to pull requests that target the default branch, but you can change this configuration within {% data variables.product.prodname_actions %} or in a third-party CI/CD system. If merging the changes would introduce new {% data variables.product.prodname_code_scanning %} alerts to the target branch, these are reported as check results in the pull request. The alerts are also shown as annotations in the **Files changed** tab of the pull request. If you have write permission for the repository, you can see any existing {% data variables.product.prodname_code_scanning %} alerts on the **Security** tab. For information about repository alerts, see "[Managing {% data variables.product.prodname_code_scanning %} alerts for your repository](/github/finding-security-vulnerabilities-and-errors-in-your-code/managing-code-scanning-alerts-for-your-repository)."
 
-If {% data variables.product.prodname_code_scanning %} has any results with a severity of `error`, the check fails and the error is reported in the check results. If all the results found by {% data variables.product.prodname_code_scanning %} have lower severities, the alerts are treated as warnings or notices and the check succeeds. If your pull request targets a protected branch that has been enabled for {% data variables.product.prodname_code_scanning %}, and the repository owner has configured required status checks, then you must either fix or {% if currentVersion == "enterprise-server@2.22" %}close{% else %}dismiss{% endif %} all error alerts before the pull request can be merged. For more information, see "[About required status checks](/github/administering-a-repository/about-required-status-checks)."
+If {% data variables.product.prodname_code_scanning %} has any results with a severity of `error`, the check fails and the error is reported in the check results. If all the results found by {% data variables.product.prodname_code_scanning %} have lower severities, the alerts are treated as warnings or notices and the check succeeds. If your pull request targets a protected branch that has been enabled for {% data variables.product.prodname_code_scanning %}, and the repository owner has configured required status checks, then you must either fix or {% if currentVersion == "enterprise-server@2.22" %}close{% else %}dismiss{% endif %} all error alerts before the pull request can be merged. For more information, see "[About protected branches](/github/administering-a-repository/about-protected-branches#require-status-checks-before-merging)."
 
 ![Failed {% data variables.product.prodname_code_scanning %} check on a pull request](/assets/images/help/repository/code-scanning-check-failure.png)
 

content/github/getting-started-with-github/keyboard-shortcuts.md

@@ -33,7 +33,7 @@ Below is a list of some of the available keyboard shortcuts.
 |-----------|------------
 |<kbd>g</kbd> <kbd>c</kbd> | Go to the **Code** tab
 |<kbd>g</kbd> <kbd>i</kbd> | Go to the **Issues** tab. For more information, see "[About issues](/articles/about-issues)."
-|<kbd>g</kbd> <kbd>p</kbd> | Go to the **Pull requests** tab. For more information, see "[About pull requests](/articles/about-pull-requests)."{% if currentVersion == "free-pro-team@latest" or currentVersion ver_gt "enterprise-server@2.21" or currentVersion == "github-ae@latest" %}
+|<kbd>g</kbd> <kbd>p</kbd> | Go to the **Pull requests** tab. For more information, see "[About pull requests](/articles/about-pull-requests)."{% if currentVersion == "free-pro-team@latest" or currentVersion ver_gt "enterprise-server@2.21" %}
 |<kbd>g</kbd> <kbd>a</kbd> | Go to the **Actions** tab. For more information, see "[About Actions](/actions/getting-started-with-github-actions/about-github-actions)."{% endif %}
 |<kbd>g</kbd> <kbd>b</kbd> | Go to the **Projects** tab. For more information, see "[About project boards](/articles/about-project-boards)."
 |<kbd>g</kbd> <kbd>w</kbd> | Go to the **Wiki** tab. For more information, see "[About wikis](/articles/about-wikis)."
@@ -159,6 +159,10 @@ For more keyboard shortcuts, see the [CodeMirror documentation](https://codemirr
 | Keyboard shortcut | Description
 |-----------|------------
 |<kbd>command + space </kbd> or <kbd>control + space</kbd> | In the workflow editor, get suggestions for your workflow file.
+|<kbd>g</kbd> <kbd>f</kbd> | Go to the workflow file
+|<kbd>shift + t</kbd> or <kbd>T</kbd> | Toggle timestamps in logs
+|<kbd>shift + f</kbd> or <kbd>F</kbd> | Toggle fullscreen logs
+|<kbd>esc</kbd> | Exit fullscreen logs
 
 {% endif %}
 

content/github/managing-security-vulnerabilities/configuring-dependabot-security-updates.md

@@ -42,17 +42,19 @@ If security updates are not enabled for your repository and you don't know why,
 
 ### Managing {% data variables.product.prodname_dependabot_security_updates %} for your repositories
 
-You can enable or disable {% data variables.product.prodname_dependabot_security_updates %} for an individual repository.
+You can enable or disable {% data variables.product.prodname_dependabot_security_updates %} for an individual repository (see below).
 
 You can also enable or disable {% data variables.product.prodname_dependabot_security_updates %} for all repositories owned by your user account or organization. For more information, see "[Managing security and analysis settings for your user account](/github/setting-up-and-managing-your-github-user-account/managing-security-and-analysis-settings-for-your-user-account)" or "[Managing security and analysis settings for your organization](/github/setting-up-and-managing-organizations-and-teams/managing-security-and-analysis-settings-for-your-organization)." 
 
 {% data variables.product.prodname_dependabot_security_updates %} require specific repository settings. For more information, see "[Supported repositories](#supported-repositories)."
 
+#### Enabling or disabling {% data variables.product.prodname_dependabot_security_updates %} for an individual repository
+
 {% data reusables.repositories.navigate-to-repo %}
-{% data reusables.repositories.sidebar-security %}
-{% data reusables.repositories.sidebar-dependabot-alerts %}
-1. Above the list of alerts, use the drop-down menu and select or unselect **{% data variables.product.prodname_dependabot %} security updates**.
-  ![Drop-down menu with the option to enable {% data variables.product.prodname_dependabot_security_updates %}](/assets/images/help/repository/enable-dependabot-security-updates-drop-down.png)
+{% data reusables.repositories.sidebar-settings %}
+{% data reusables.repositories.navigate-to-security-and-analysis %}
+1. Under "Configure security and analysis features", to the right of "{% data variables.product.prodname_dependabot %} security updates", click **Enable** or **Disable**.
+  !["Configure security and analysis features" section with button to enable {% data variables.product.prodname_dependabot_security_updates %}](/assets/images/help/repository/enable-dependabot-security-updates-button.png)
 
 ### Further reading
 

content/github/managing-your-work-on-github/about-issues.md

@@ -14,9 +14,11 @@ versions:
 
 You can collect user feedback, report software bugs, and organize tasks you'd like to accomplish with issues in a repository. Issues can act as more than just a place to report software bugs.
 
+{% if currentVersion == "free-pro-team@latest" %}
 Other conversations are more suitable for discussions. {% data reusables.discussions.you-can-use-discussions %}
 
 {% data reusables.discussions.you-cannot-convert-a-discussion %}
+{% endif %}
 
 {% data reusables.pull_requests.close-issues-using-keywords %}
 

content/github/managing-your-work-on-github/filtering-pull-requests-by-review-status.md

@@ -11,7 +11,7 @@ versions:
 
 You can filter a repository's list of pull requests to find:
 - Pull requests that haven't been [reviewed](/articles/about-pull-request-reviews) yet
-- Pull requests that [require a review](/articles/about-required-reviews-for-pull-requests) before they can be merged
+- Pull requests that [require a review](/github/administering-a-repository/about-protected-branches#require-pull-request-reviews-before-merging) before they can be merged
 - Pull requests that a reviewer has approved
 - Pull requests in which a reviewer has asked for changes
 - Pull requests that you have reviewed

content/github/managing-your-work-on-github/managing-labels.md

@@ -27,7 +27,7 @@ versions:
 
 You can manage your work on {% data variables.product.product_name %} by creating labels to categorize issues and pull requests. You can apply labels in the repository the label was created in. Once a label exists, you can use the label on any issue or pull request within that repository.
 
-Anyone with read access to a repository can view and search the repository’s labels. To create, edit, apply, or delete a label, you must have write access to the repository.
+Anyone with read access to a repository can view and search the repository’s labels. Anyone with triage access to a repository can apply/dismiss existing labels. To create, edit, apply, or delete a label, you must have write access to the repository.
 
 ### About default labels
 

content/github/managing-your-work-on-github/using-search-to-filter-issues-and-pull-requests.md

@@ -36,7 +36,7 @@ For issues, you can also use search to:
 For pull requests, you can also use search to:
 - Filter [draft](/articles/about-pull-requests#draft-pull-requests) pull requests: `is:draft`
 - Filter pull requests that haven't been [reviewed](/articles/about-pull-request-reviews) yet: `state:open type:pr review:none`
-- Filter pull requests that [require a review](/articles/about-required-reviews-for-pull-requests) before they can be merged: `state:open type:pr review:required`
+- Filter pull requests that [require a review](/github/administering-a-repository/about-protected-branches#require-pull-request-reviews-before-merging) before they can be merged: `state:open type:pr review:required`
 - Filter pull requests that a reviewer has approved: `state:open type:pr review:approved`
 - Filter pull requests in which a reviewer has asked for changes: `state:open type:pr review:changes_requested`
 - Filter pull requests by [reviewer](/articles/about-pull-request-reviews/): `state:open type:pr reviewed-by:octocat`

content/github/setting-up-and-managing-organizations-and-teams/repository-permission-levels-for-an-organization.md

@@ -58,7 +58,7 @@ In addition to managing organization-level settings, organization owners have ad
 | View [GitHub Actions workflow runs](/actions/automating-your-workflow-with-github-actions/managing-a-workflow-run) | **X** | **X** | **X** | **X** | **X** |{% endif %}
 | Edit wikis | **X** | **X** | **X** | **X** | **X** |{% if currentVersion == "free-pro-team@latest" %}
 | [Report abusive or spammy content](/articles/reporting-abuse-or-spam) | **X** | **X** | **X** | **X** | **X** |{% endif %}
-| Apply labels | | **X** | **X** | **X** | **X** |
+| Apply/dismiss labels | | **X** | **X** | **X** | **X** |
 | Create, edit, delete labels | | | **X** | **X** | **X** |
 | Close, reopen, and assign all issues and pull requests | | **X** | **X** | **X** | **X** |{% if currentVersion == "free-pro-team@latest" %}
 | [Enable and disable auto-merge on a pull request](/github/administering-a-repository/managing-auto-merge-for-pull-requests-in-your-repository) | | | **X** | **X** | **X** |{% endif %}

content/github/site-policy-deprecated/amendment-to-github-terms-of-service-applicable-to-us-federal-government-users.md

@@ -6,6 +6,7 @@ redirect_from:
   - /articles/proposed-amendment-to-github-terms-of-service-applicable-to-u-s-federal-government-users/
   - /articles/amendment-to-github-terms-of-service-applicable-to-u-s-federal-government-users
   - /articles/amendment-to-github-terms-of-service-applicable-to-us-federal-government-users
+  - /github/site-policy/amendment-to-github-terms-of-service-applicable-to-us-federal-government-users
 versions:
   free-pro-team: '*'
 ---

content/github/site-policy-deprecated/github-ae-data-protection-agreement.md

@@ -5,6 +5,7 @@ versions:
   free-pro-team: '*'
 redirect_from:
   - /github/site-policy/ghem-data-protection-addendum
+  - /github/site-policy/github-ae-data-protection-agreement
 ---
 
 _These terms apply to Customers who licensed the Products prior to January 4, 2021._

content/github/site-policy-deprecated/github-ae-product-specific-terms.md

@@ -5,6 +5,7 @@ versions:
   free-pro-team: '*'
 redirect_from:
   - /github/site-policy/ghem-supplemental-terms-for-microsoft-volume-licensing
+  - /github/site-policy/github-ae-product-specific-terms
 ---
 
 _These terms apply to Customers who licensed the Products prior to January 4, 2021._

content/github/site-policy-deprecated/github-connect-addendum-to-the-github-enterprise-license-agreement.md

@@ -4,6 +4,7 @@ hidden: true
 redirect_from:
   - /articles/github-com-connection-addendum-to-the-github-enterprise-license-agreement/
   - /articles/github-connect-addendum-to-the-github-enterprise-license-agreement
+  - /github/site-policy/github-connect-addendum-to-the-github-enterprise-license-agreement
 versions:
   free-pro-team: '*'
 ---

content/github/site-policy-deprecated/github-data-protection-addendum.md

@@ -1,6 +1,8 @@
 ---
 title: GitHub Data Protection Addendum
 hidden: true
+redirect_from:
+  - /github/site-policy/github-data-protection-addendum
 versions:
   free-pro-team: '*'
 ---

content/github/site-policy-deprecated/github-enterprise-cloud-evaluation-agreement.md

@@ -3,6 +3,7 @@ title: GitHub Enterprise Cloud Evaluation Agreement
 hidden: true
 redirect_from:
   - /articles/github-enterprise-cloud-evaluation-agreement
+  - /github/site-policy/github-enterprise-cloud-evaluation-agreement
 versions:
   free-pro-team: '*'
 ---

content/github/site-policy-deprecated/github-enterprise-server-license-agreement.md

@@ -3,6 +3,7 @@ title: GitHub Enterprise Server License Agreement
 hidden: true
 redirect_from:
   - /articles/github-enterprise-server-license-agreement
+  - /github/site-policy/github-enterprise-server-license-agreement
 versions:
   free-pro-team: '*'
 ---

content/github/site-policy-deprecated/github-enterprise-service-level-agreement.md

@@ -5,6 +5,7 @@ redirect_from:
   - /github-enterprise-cloud-addendum/
   - /github-business-cloud-addendum/
   - /articles/github-enterprise-cloud-addendum
+  - /github/site-policy/github-enterprise-service-level-agreement
 versions:
   free-pro-team: '*'
 ---

content/github/site-policy-deprecated/github-enterprise-subscription-agreement.md

@@ -4,6 +4,7 @@ hidden: true
 redirect_from:
   - /articles/github-enterprise-agreement/
   - /articles/github-enterprise-subscription-agreement
+  - /github/site-policy/github-enterprise-subscription-agreement
 versions:
   free-pro-team: '*'
 ---

content/github/site-policy-deprecated/github-supplemental-terms-for-microsoft-volume-licensing.md

@@ -4,6 +4,7 @@ hidden: true
 redirect_from:
   - /articles/GitHub-Supplemental-Terms-for-Microsoft-Volume-Licensing/
   - /articles/github-supplemental-terms-for-microsoft-volume-licensing
+  - /github/site-policy/github-supplemental-terms-for-microsoft-volume-licensing
 versions:
   free-pro-team: '*'
 ---

content/github/site-policy/index.md

@@ -13,17 +13,8 @@ versions:
 {% link_in_list /github-terms-of-service %}
 {% link_in_list /github-corporate-terms-of-service %}
 {% link_in_list /github-privacy-statement %}
-{% link_in_list /github-data-protection-addendum %}
 {% link_in_list /global-privacy-practices %}
-{% link_in_list /github-enterprise-server-license-agreement %}
-{% link_in_list /github-ae-data-protection-agreement %}
-{% link_in_list /github-ae-product-specific-terms %}
-{% link_in_list /github-enterprise-service-level-agreement %}
-{% link_in_list /github-connect-addendum-to-the-github-enterprise-license-agreement %}
-{% link_in_list /github-supplemental-terms-for-microsoft-volume-licensing %}
-{% link_in_list /github-enterprise-subscription-agreement %}
 {% link_in_list /github-insights-and-data-protection-for-your-organization %}
-{% link_in_list /github-enterprise-cloud-evaluation-agreement %}
 {% link_in_list /github-sponsors-additional-terms %}
 {% link_in_list /github-additional-product-terms %}
 {% link_in_list /github-logo-policy %}
@@ -37,7 +28,6 @@ versions:
 {% link_in_list /github-subprocessors-and-cookies %}
 {% link_in_list /github-bug-bounty-program-legal-safe-harbor %}
 {% link_in_list /responsible-disclosure-of-security-vulnerabilities %}
-{% link_in_list /amendment-to-github-terms-of-service-applicable-to-us-federal-government-users %}
 {% link_in_list /guidelines-for-legal-requests-of-user-data %}
 {% link_in_list /github-government-takedown-policy %}
 {% link_in_list /github-acceptable-use-policies %}

content/github/using-git/using-git-rebase-on-the-command-line.md

@@ -124,6 +124,10 @@ As before, Git is showing the commit message for you to edit. You can change the
 Since you've altered Git history, the usual `git push origin` **will not** work. You'll need to modify the command by "force-pushing" your latest changes:
 
 ```shell
+# Don't override changes
+$ git push origin main --force-with-lease
+
+# Override changes
 $ git push origin main --force
 ```
 

content/github/working-with-github-pages/adding-content-to-your-github-pages-site-using-jekyll.md

@@ -62,6 +62,8 @@ Your theme includes default layouts, includes, and stylesheets that will automat
 {% data reusables.files.choose_commit_branch %}
 {% data reusables.files.propose_file_change %}
 
+Your post should now be up on your site! If the base URL of your site is `https://octocat.github.io`, then your new post will be located at `https://octocat.github.io/YYYY/MM/DD/TITLE.html`.
+
 ### Next steps
 
 {% data reusables.pages.add-jekyll-theme %} For more information, see "[Adding a theme to your {% data variables.product.prodname_pages %} site using Jekyll](/articles/adding-a-theme-to-your-github-pages-site-using-jekyll)."

content/graphql/guides/forming-calls-with-graphql.md

@@ -103,6 +103,7 @@ Mutations are structured like this:
 <pre>mutation {
   <em>mutationName</em>(input: {<em>MutationNameInput!</em>}) {
     <em>MutationNamePayload</em>
+  }
 }</pre>
 
 The input object in this example is `MutationNameInput`, and the payload object is `MutationNamePayload`.

content/packages/learn-github-packages/about-github-packages.md

@@ -152,7 +152,7 @@ For more information, see:
 
 ### Managing packages
 
-You can delete a version of a private package on {% data variables.product.product_name %} or using the GraphQL API. When you use the GraphQL API to query and delete private packages, you must use the same token you use to authenticate to {% data variables.product.prodname_registry %}. For more information, see "[Deleting a package](/packages/manage-packages/deleting-a-package)" and "[Forming calls with GraphQL](/graphql/guides/forming-calls-with-graphql)."
+You can delete a version of a private package in the {% data variables.product.product_name %} user interface or using the GraphQL API. When you use the GraphQL API to query and delete private packages, you must use the same token you use to authenticate to {% data variables.product.prodname_registry %}. For more information, see "[Deleting a package](/packages/manage-packages/deleting-a-package)" and "[Forming calls with GraphQL](/graphql/guides/forming-calls-with-graphql)."
 
 You can configure webhooks to subscribe to package-related events, such as when a package is published or updated. For more information, see the "[`package` webhook event](/webhooks/event-payloads/#package)."
 

content/rest/overview/resources-in-the-rest-api.md

@@ -31,7 +31,7 @@ For information about GitHub's GraphQL API, see the [v4 documentation](/graphql)
 sent and received as JSON.
 
 ```shell
-$ curl -i {% data variables.product.api_url_pre %}/users/octocat/orgs
+$ curl -I {% data variables.product.api_url_pre %}/users/octocat/orgs
 
 > HTTP/1.1 200 OK
 > Server: nginx
@@ -137,7 +137,7 @@ Read [more about unauthenticated rate limiting](#increasing-the-unauthenticated-
 Authenticating with invalid credentials will return `401 Unauthorized`:
 
 ```shell
-$ curl -i {% data variables.product.api_url_pre %} -u foo:bar
+$ curl -I {% data variables.product.api_url_pre %} -u foo:bar
 > HTTP/1.1 401 Unauthorized
 
 > {
@@ -369,7 +369,7 @@ Note that [the Search API has custom rate limit rules](/rest/reference/search#ra
 The returned HTTP headers of any API request show your current rate limit status:
 
 ```shell
-$ curl -i {% data variables.product.api_url_pre %}/users/octocat
+$ curl -I {% data variables.product.api_url_pre %}/users/octocat
 > HTTP/1.1 200 OK
 > Date: Mon, 01 Jul 2013 17:27:06 GMT
 > Status: 200 OK
@@ -469,7 +469,7 @@ User-Agent: Awesome-Octocat-App
 cURL sends a valid `User-Agent` header by default. If you provide an invalid `User-Agent` header via cURL (or via an alternative client), you will receive a `403 Forbidden` response:
 
 ```shell
-$ curl -iH 'User-Agent: ' {% data variables.product.api_url_pre %}/meta
+$ curl -IH 'User-Agent: ' {% data variables.product.api_url_pre %}/meta
 > HTTP/1.0 403 Forbidden
 > Connection: close
 > Content-Type: text/html
@@ -501,7 +501,7 @@ whenever possible.
 {% endif %}
 
 ```shell
-$ curl -i {% data variables.product.api_url_pre %}/user
+$ curl -I {% data variables.product.api_url_pre %}/user
 > HTTP/1.1 200 OK
 > Cache-Control: private, max-age=60
 > ETag: "644b5b0155e6404a9cc4bd9d8b1ae730"
@@ -512,7 +512,7 @@ $ curl -i {% data variables.product.api_url_pre %}/user
 > X-RateLimit-Remaining: 4996
 > X-RateLimit-Reset: 1372700873
 
-$ curl -i {% data variables.product.api_url_pre %}/user -H 'If-None-Match: "644b5b0155e6404a9cc4bd9d8b1ae730"'
+$ curl -I {% data variables.product.api_url_pre %}/user -H 'If-None-Match: "644b5b0155e6404a9cc4bd9d8b1ae730"'
 > HTTP/1.1 304 Not Modified
 > Cache-Control: private, max-age=60
 > ETag: "644b5b0155e6404a9cc4bd9d8b1ae730"
@@ -523,7 +523,7 @@ $ curl -i {% data variables.product.api_url_pre %}/user -H 'If-None-Match: "644b
 > X-RateLimit-Remaining: 4996
 > X-RateLimit-Reset: 1372700873
 
-$ curl -i {% data variables.product.api_url_pre %}/user -H "If-Modified-Since: Thu, 05 Jul 2012 15:31:30 GMT"
+$ curl -I {% data variables.product.api_url_pre %}/user -H "If-Modified-Since: Thu, 05 Jul 2012 15:31:30 GMT"
 > HTTP/1.1 304 Not Modified
 > Cache-Control: private, max-age=60
 > Last-Modified: Thu, 05 Jul 2012 15:31:30 GMT
@@ -546,7 +546,7 @@ Here's a sample request sent from a browser hitting
 `http://example.com`:
 
 ```shell
-$ curl -i {% data variables.product.api_url_pre %} -H "Origin: http://example.com"
+$ curl -I {% data variables.product.api_url_pre %} -H "Origin: http://example.com"
 HTTP/1.1 302 Found
 Access-Control-Allow-Origin: *
 Access-Control-Expose-Headers: ETag, Link, X-GitHub-OTP, X-RateLimit-Limit, X-RateLimit-Remaining, X-RateLimit-Reset, X-OAuth-Scopes, X-Accepted-OAuth-Scopes, X-Poll-Interval
@@ -555,7 +555,7 @@ Access-Control-Expose-Headers: ETag, Link, X-GitHub-OTP, X-RateLimit-Limit, X-Ra
 This is what the CORS preflight request looks like:
 
 ```shell
-$ curl -i {% data variables.product.api_url_pre %} -H "Origin: http://example.com" -X OPTIONS
+$ curl -I {% data variables.product.api_url_pre %} -H "Origin: http://example.com" -X OPTIONS
 HTTP/1.1 204 No Content
 Access-Control-Allow-Origin: *
 Access-Control-Allow-Headers: Authorization, Content-Type, If-Match, If-Modified-Since, If-None-Match, If-Unmodified-Since, X-GitHub-OTP, X-Requested-With

contributing/content-style-guide.md

@@ -276,7 +276,7 @@ Take care to distinguish between product names and product elements. For more in
 Follow standard American English punctuation rules. For more guidance, see “[Punctuation](https://brand.github.com/content/grammar#punctuation)” in GitHub’s Brand Guide and “[Punctuation](https://docs.microsoft.com/style-guide/punctuation)” in the Microsoft Style Guide.
 
 ## Reusables and variables
-Use reusable strings for individual nouns (e.g. product names) or for complete sentences or paragraphs. Sentence fragments and phrases should not be contained in reusable strings as they can cause problems when content is localized. For more information, see the data directory in the github/docs repository and the “Product names” section of this document.
+Use reusable strings for individual nouns (e.g. product names) or for complete sentences or paragraphs. Sentence fragments and phrases should not be contained in reusable strings as they can cause problems when content is localized. For more information, see the [data directory](../data) in the github/docs repository and the “[Product names](#product-names)” section of this document.
 
 ## Tables
 

contributing/development.md

@@ -48,7 +48,7 @@ For more detailed instructions, please see this [VS Code recipe](https://github.
 
 While running the local server, you can visit [localhost:4000/dev-toc](http://localhost:4000/dev-toc) to view a top-level TOC of all the content in the site. This page is not available on https://docs.github.com. It was created for internal GitHub writers' use.
 
-At the `/dev-toc` path, you'll see a list of available versions. Click a version, and a list of products will appear. Note that the TOC content is versioned. If you are viewing `free-pro-team@latest` and you click the `Enterprise Admin` product, it will be empty, because there isn't any Admin content available on that version.
+At the `/dev-toc` path, you'll see a list of available versions. Click a version, and a list of products will appear. Note that the TOC content is versioned. If you are viewing the `GitHub.com` version and you click the `Enterprise Admin` product, it will be empty, because there isn't any Admin content available on that version.
 
 ## Site structure
 

contributing/permalinks.md

@@ -4,7 +4,7 @@ Because the site is dynamic, it does not build HTML files for each different ver
 
 For example, an article that is available in currently supported versions will have permalink URLs like the following:
 
-* `/en/free-pro-team@latest/github/getting-started-with-github/set-up-git`
+* `/en/github/getting-started-with-github/set-up-git`
 * `/en/enterprise-server@2.22/github/getting-started-with-github/set-up-git`
 * `/en/enterprise-server@2.21/github/getting-started-with-github/set-up-git`
 * `/en/enterprise-server@2.20/github/getting-started-with-github/set-up-git`
@@ -12,10 +12,8 @@ For example, an article that is available in currently supported versions will h
 
 An article that is not available in Enterprise will have just one permalink:
 
-* `/en/free-pro-team@latest/github/getting-started-with-github/set-up-git`
+* `/en/github/getting-started-with-github/set-up-git`
 
 **If you are a content contributor:** You don't need to worry about supported versions when adding a link to a document. Following the examples above, if you want to reference an article you can just use its relative location:
 
-* `/github/getting-started-with-github/set-up-git`
-
-*(Please note that using a hard-coded link or supported version will result in an error when your submitted PR is automatically tested)*
+* `/github/getting-started-with-github/set-up-git`

crowdin.yml

@@ -4,16 +4,7 @@ files:
     ignore:
       - '/content/README.md'
       - '/content/early-access'
-      - '/content/github/site-policy/github-enterprise-cloud-evaluation-agreement.md'
-      - '/content/github/site-policy/github-enterprise-service-level-agreement.md'
-      - '/content/github/site-policy/github-enterprise-server-license-agreement.md'
-      - '/content/github/site-policy/github-supplemental-terms-for-microsoft-volume-licensing.md'
-      - '/content/github/site-policy/github-ae-product-specific-terms.md'
-      - '/content/github/site-policy/amendment-to-github-terms-of-service-applicable-to-us-federal-government-users.md'
-      - '/content/github/site-policy/github-enterprise-subscription-agreement.md'
-      - '/content/github/site-policy/github-data-protection-addendum.md'
-      - '/content/github/site-policy/github-connect-addendum-to-the-github-enterprise-license-agreement.md'
-      - '/content/github/site-policy/github-ae-data-protection-agreement.md'
+      - '/content/github/site-policy-deprecated'
   - source: /data/**/*.yml
     translation: /translations/%locale%/%original_path%/%original_file_name%
   - source: /data/**/*.md

data/release-notes/2-22/0.yml

@@ -90,6 +90,19 @@ sections:
 
           * [The GraphQL schema changes](https://docs.github.com/enterprise/2.22/user/graphql/overview/changelog) include backwards-compatible changes, schema previews, and upcoming breaking changes.
 
+    - heading: VMware Network Driver Changes
+      notes:
+        - |
+          The GitHub Enterprise Server default network adapter type for VMware customers has been changed from E1000 to VMXNET3, starting with release 2.22.0. When upgrading from an earlier release to 2.22.0 or newer, if an E1000 network adapter is detected during the pre-upgrade check, the following message will be displayed at the command line:
+
+          ```
+          WARNING: Your virtual appliance is currently using an emulated Intel E1000 network adapter.
+          For optimal performance, please update the virtual machine configuration on your VMware host to use the VMXNET3 driver.
+          Proceed with installation? [y/N]
+          ```
+
+          The administrator can choose to update the network adapter type to VMXNET3 either before or after the GitHub Enterprise Server upgrade. The virtual appliance will need to be shutdown for this change. Customers should follow the VMware recommended steps for [changing the virtual machine network adapter configuration](https://docs.vmware.com/en/VMware-vSphere/7.0/com.vmware.vsphere.vm_admin.doc/GUID-3719A0BE-4B4A-44FF-8A21-290950918FBD.html) to VMXNET3. Please note that `VMXNET3` will not be an option if the OS version for the virtual appliance is set to `Other Linux (64-bit)`. In that case, the OS version would first need to be changed from `Other Linux (64-bit)` to `Other 2.6.x Linux (64-bit)` or if available, `Debian GNU/Linux 9` . We recommend testing these changes on a [staging instance](https://docs.github.com/en/enterprise-server@2.22/admin/installation/setting-up-a-staging-instance) before it is performed on a production GitHub Enterprise Server. {% comment %} https://github.com/github/ghes-infrastructure/issues/781 {% endcomment %}
+
   bugs:
     - The stafftools page for viewing pending collaborator showed a `500 Internal Server Error` when there was a pending email invite. {% comment %} https://github.com/github/github/pull/150836 {% endcomment %}
     - The Repository Health Check in stafftools could give incorrect results on busy repositories. {% comment %} https://github.com/github/github/pull/151160 {% endcomment %}
@@ -111,8 +124,8 @@ sections:
       notes:
         - GitHub no longer supports the OAuth application endpoints that contain `access_token` as a path parameter. We have introduced new endpoints that allow you to securely manage tokens for OAuth Apps by moving `access_token` to the request body. While deprecated, the endpoints are still accessible in this version. We intend to remove these endpoints on GitHub Enterprise Server 3.4. For more information, see the [deprecation announcement blog post](https://developer.github.com/changes/2020-02-14-deprecating-oauth-app-endpoint/).
 
-  # - type: Backup and Disaster recovery
-  #   note: GitHub Enterprise Server 2.22 requires at least [GitHub Enterprise Backup Utilities](https://github.com/github/backup-utils) 2.22.0 for [Backups and Disaster Recovery](https://help.github.com/enterprise/2.22/admin/guides/installation/backups-and-disaster-recovery/).
+  backups:
+    - GitHub Enterprise Server 2.22 requires at least [GitHub Enterprise Backup Utilities](https://github.com/github/backup-utils) 2.22.0 for [Backups and Disaster Recovery](https://help.github.com/enterprise/2.22/admin/guides/installation/backups-and-disaster-recovery/).
 
   known_issues:
     - On a freshly set up GitHub Enterprise Server without any users, an attacker could create the first admin user. {% comment %} https://github.com/github/enterprise2/issues/1889 {% endcomment %}

data/release-notes/3-0/0-rc.yml

@@ -134,6 +134,7 @@ sections:
     - '`ghe-config-apply` occassionally fails with `ERROR: Failure waiting for nomad jobs to apply` until the Nomad job queue is cleared. This currently requires as admin to delete `/etc/nomad-jobs/queue`.'
     - When configuring a multiple replica node, the status of the replica can be incorrectly synchronized.
     - Customers attempting to restore a 3.0 backup to a new instance should not pre-configure the instance, as it may lead to a bad state for user logins. We recommend restoring to a fresh, unconfigured instance.
+    - GitHub Enterprise Server 3.0 release candidates are not yet available in the Azure marketplace. To test RC1 in staging environments, start a 2.21 or 2.22 instance, and then upgrade it with the Azure upgrade package on the download page.
 
   backups:
     - '{% data variables.product.prodname_ghe_server %} 3.0 requires at least [GitHub Enterprise Backup Utilities 3.0.0](https://github.com/github/backup-utils) for [Backups and Disaster Recovery](/enterprise-server@3.0/admin/configuration/configuring-backups-on-your-appliance).'

data/reusables/gated-features/branch-restrictions.md

@@ -1,3 +0,0 @@
-{% data reusables.gated-features.protected-branches %} 
-<br>
-Branch restriction is a type of branch protection that's available for public and private repositories owned by organizations in {% data variables.product.prodname_team %}, {% data variables.product.prodname_ghe_cloud %},{% if currentVersion == "github-ae@latest" %} {% data variables.product.prodname_ghe_managed %},{% endif %} and {% data variables.product.prodname_ghe_server %}. {% if currentVersion == "free-pro-team@latest" %}{% data reusables.gated-features.more-info %}{% endif %}

data/reusables/gated-features/protected-branches.md

@@ -1 +1 @@
-Protected branches are available in public repositories with {% data variables.product.prodname_free_user %} and {% data variables.product.prodname_free_team %} for organizations, and in public and private repositories with {% data variables.product.prodname_pro %}, {% data variables.product.prodname_team %}, {% data variables.product.prodname_ghe_cloud %},{% if currentVersion == "github-ae@latest" %} {% data variables.product.prodname_ghe_managed %},{% endif %} and {% data variables.product.prodname_ghe_server %}. {% if currentVersion == "free-pro-team@latest" %}{% data reusables.gated-features.more-info %}{% endif %}
+{% if currentVersion == "github-ae@latest" %}Protected branches are available in internal and private repositories with {% data variables.product.prodname_ghe_managed %}, {% else%}Protected branches are available {% endif %}in public repositories with {% data variables.product.prodname_free_user %} and {% data variables.product.prodname_free_team %} for organizations, and in public and private repositories with {% data variables.product.prodname_pro %}, {% data variables.product.prodname_team %}, {% data variables.product.prodname_ghe_cloud %}, and {% data variables.product.prodname_ghe_server %}. {% if currentVersion == "free-pro-team@latest" %}{% data reusables.gated-features.more-info %}{% endif %}

data/reusables/pull_requests/about-protected-branches.md

@@ -1 +0,0 @@
-By default, any pull request can be merged at any time, unless the head branch is in conflict with the base branch. 

data/reusables/pull_requests/required-checks-must-pass-to-merge.md

@@ -1 +1 @@
-If status checks are required for a repository, the required status checks must pass before you can merge your branch into the protected branch. For more information, see "[About required status checks](/articles/about-required-status-checks)."
+If status checks are required for a repository, the required status checks must pass before you can merge your branch into the protected branch. For more information, see "[About protected branches](/github/administering-a-repository/about-protected-branches#require-status-checks-before-merging)."

data/reusables/pull_requests/required-reviews-for-prs-summary.md

@@ -1,3 +1 @@
-Repository administrators can require that all pull requests receive a specific number of approving reviews from people with *write* or *admin* permissions in the repository or from a designated code owner before they're merged into a protected branch. For more information, see "[About protected branches](/articles/about-protected-branches)."
-
-When required reviews are enabled, anyone with access to the repository can approve changes in a pull request. However, you won't be able to merge your pull request until the required number of reviewers with *write* or *admin* permissions in the repository approve your pull request's changes in their review. For more information about repository permission levels, see "[Repository permission levels for an organization](/articles/repository-permission-levels-for-an-organization/)." If review is required from a designated code owner and the pull request affects code that has a designated owner, approval from that owner is required.
+Repository administrators can require that all pull requests receive a specific number of approving reviews before someone merges the pull request into a protected branch. You can require approving reviews from people with write permissions in the repository or from a designated code owner.

data/reusables/repositories/branch-rules-example.md

@@ -1 +1 @@
-You can create a branch rule in a repository for a specific branch, all branches, or any branch that matches a naming pattern specified with the fnmatch syntax. For example, to require any branch containing the word `release` to have at least two pull request reviews before merging, you can create a branch rule for `*release*`.
+You can create a branch protection rule in a repository for a specific branch, all branches, or any branch that matches a name pattern you specify with `fnmatch` syntax. For example, to protect any branches containing the word `release`, you can create a branch rule for `*release*`.

data/reusables/repositories/include-administrators.md

@@ -1,2 +0,0 @@
-1. Optionally, select **Include administrators**. This enforces all configured restrictions for repository administrators.
-![Include administrators checkbox](/assets/images/help/repository/include-admins-protected-branches.png)

data/reusables/repositories/protected-branches-options.md

@@ -1 +0,0 @@
-You can automatically enforce protected branch settings for some or all branches in your repository. For more information, see "[Configuring protected branches](/github/administering-a-repository/configuring-protected-branches)."

data/reusables/repositories/required-status-merge-tip.md

@@ -1,5 +0,0 @@
-{% tip %}
-
-**Tip:** To successfully merge a pull request into a base branch that has required status checks enabled, the pull request's head branch must be up-to-date with the base branch.
-
-{% endtip %}

data/reusables/repositories/review-policy-overlapping-commits.md

@@ -1 +1 @@
-After all required reviewers have approved a pull request, you won't be able to merge it if there are other open pull requests with pending or rejected reviews and those pull requests have a head branch pointing to the same commit. Someone with *write* or *admin* permissions will need to approve or dismiss the blocking review on the other pull requests before you can merge.
+Even after all required reviewers have approved a pull request, collaborators cannot merge the pull request if there are other open pull requests that have a head branch pointing to the same commit with pending or rejected reviews. Someone with write permissions must approve or dismiss the blocking review on the other pull requests first.

data/reusables/repositories/squash-and-rebase-linear-commit-hisitory.md

@@ -1 +1 @@
-{% if currentVersion == "free-pro-team@latest" or currentVersion ver_gt "enterprise-server@2.19" or currentVersion == "github-ae@latest" %}If there is a protected branch rule in your repository that requires a linear commit history, you must allow squash merging, rebase merging, or both. For more information, see "[Requiring a linear commit history](/github/administering-a-repository/requiring-a-linear-commit-history)."{% endif %}
+{% if currentVersion == "free-pro-team@latest" or currentVersion ver_gt "enterprise-server@2.19" or currentVersion == "github-ae@latest" %}If there is a protected branch rule in your repository that requires a linear commit history, you must allow squash merging, rebase merging, or both. For more information, see "[About protected branches](/github/administering-a-repository/about-protected-branches#require-pull-request-reviews-before-merging)."{% endif %}

includes/footer.html

@@ -21,9 +21,9 @@
         <h4 class="mb-3 text-mono text-gray-light text-normal">{% data ui.footer.platform.heading %}</h4>
         <ul class="list-style-none f5">
           <li class="lh-condensed mb-3"><a href="/developers" class="link-gray">{% data ui.footer.platform.links.developer_api %}</a></li>
-          <li class="lh-condensed mb-3"><a href="http://partner.github.com/" class="link-gray">{% data ui.footer.platform.links.partners %}</a></li>
+          <li class="lh-condensed mb-3"><a href="https://partner.github.com/" class="link-gray">{% data ui.footer.platform.links.partners %}</a></li>
           <li class="lh-condensed mb-3"><a href="https://atom.io" class="link-gray">{% data ui.footer.platform.links.atom %}</a></li>
-          <li class="lh-condensed mb-3"><a href="http://electron.atom.io/" class="link-gray">{% data ui.footer.platform.links.electron %}</a></li>
+          <li class="lh-condensed mb-3"><a href="https://www.electronjs.org/" class="link-gray">{% data ui.footer.platform.links.electron %}</a></li>
           <li class="lh-condensed mb-3"><a href="https://desktop.github.com/" class="link-gray">{% data ui.footer.platform.links.github_desktop %}</a></li>
         </ul>
       </div>
@@ -33,7 +33,7 @@
           <li class="lh-condensed mb-3"><a href="/" class="link-gray">{% data ui.footer.support.links.help %}</a></li>
           <li class="lh-condensed mb-3"><a href="https://github.community" class="link-gray">{% data ui.footer.support.links.community_forum %}</a></li>
           <li class="lh-condensed mb-3"><a href="https://services.github.com/" class="link-gray">{% data ui.footer.support.links.training %}</a></li>
-          <li class="lh-condensed mb-3"><a href="https://githubstatus.com/" class="link-gray">{% data ui.footer.support.links.status %}</a></li>
+          <li class="lh-condensed mb-3"><a href="https://www.githubstatus.com/" class="link-gray">{% data ui.footer.support.links.status %}</a></li>
           <li class="lh-condensed mb-3"><a href="https://support.github.com/contact" class="link-gray">{% data ui.footer.support.links.contact_github %}</a></li>
         </ul>
       </div>

includes/liquid-tags/link-with-short-title.html

@@ -1 +0,0 @@
-<a class="link-title Bump-link--hover no-underline" href="{{ fullPath }}">{{ title }}</a>

includes/small-footer.html

@@ -8,7 +8,7 @@
       <li class="ml-3"><a href="/github/site-policy/github-terms-of-service">{% data ui.footer.terms %} </a></li>
       <li class="ml-3"><a href="/github/site-policy/github-privacy-statement">{% data ui.footer.privacy %} </a></li>
       <li class="ml-3"><a href="https://github.com/security">{% data ui.footer.product.links.security %}</a></li>
-      <li class="ml-3"><a href="https://githubstatus.com/">{% data ui.footer.support.links.status %}</a></li>
+      <li class="ml-3"><a href="https://www.githubstatus.com/">{% data ui.footer.support.links.status %}</a></li>
       <li class="ml-3"><a href="/">{% data ui.footer.support.links.help %}</a></li>
       <li class="ml-3"><a href="https://support.github.com/contact">{% data ui.footer.support.links.contact_github %}</a></li>
       <li class="ml-3"><a href="https://github.com/pricing">{% data ui.footer.product.links.pricing %}</a></li>

lib/all-products.js

@@ -7,6 +7,7 @@ const yaml = require('js-yaml')
 const contentDir = path.join(process.cwd(), 'content')
 const frontmatter = require('@github-docs/frontmatter')
 const getApplicableVersions = require('./get-applicable-versions')
+const removeFPTFromPath = require('./remove-fpt-from-path')
 
 // the product order is determined by data/products.yml
 const productsFile = path.join(process.cwd(), 'data/products.yml')
@@ -46,7 +47,7 @@ sortedProductIds.forEach(productId => {
   const toc = slash(path.join(dir, 'index.md'))
   const { data } = frontmatter(fs.readFileSync(toc, 'utf8'))
   const applicableVersions = getApplicableVersions(data.versions, toc)
-  const href = slash(path.join('/', applicableVersions[0], productId))
+  const href = removeFPTFromPath(slash(path.join('/', applicableVersions[0], productId)))
 
   internalProducts[productId] = {
     id: productId,

lib/all-versions.js

@@ -7,9 +7,10 @@ const versionDelimiter = '@'
 const latestNonNumberedRelease = 'latest'
 
 const plans = [
-  {
+  { // free-pro-team is **not** a user-facing version and is stripped from URLs.
+    // See lib/remove-fpt-from-path.js for details.
     plan: 'free-pro-team',
-    planTitle: 'Free, Pro, and Team',
+    planTitle: 'GitHub.com',
     releases: [latestNonNumberedRelease],
     latestRelease: latestNonNumberedRelease,
     nonEnterpriseDefault: true, // permanent way to refer to this plan if the name changes

lib/find-page-in-version.js

@@ -1,22 +0,0 @@
-const findPage = require('./find-page')
-const getApplicableVersions = require('./get-applicable-versions')
-
-module.exports = function findPageInVersion (href, pageMap, redirects, languageCode, version, isDotcomOnly = false) {
-  // findPage() will throw an error if an English page can't be found
-  const page = findPage(href, pageMap, redirects, languageCode)
-  if (!page) return null
-
-  // if the link is on the homepage, return the page as soon as it's found
-  if (version === 'homepage') return page
-
-  // if the link is dotcom-only, return the page as soon as it's found
-  if (isDotcomOnly) return page
-
-  // otherwise, get the versions that the found page is available in
-  const applicableVersions = getApplicableVersions(page.versions, page.fullPath)
-
-  // return null if the found page's available versions do not include the specified version
-  if (!applicableVersions.includes(version)) return null
-
-  return page
-}

lib/find-page.js

@@ -1,69 +1,17 @@
-const slash = require('slash')
-const patterns = require('./patterns')
-const allVersions = Object.keys(require('./all-versions'))
-const { getVersionedPathWithLanguage } = require('./path-utils')
+const { getLanguageCode } = require('./patterns')
 
-module.exports = function findPage (href, pageMap, redirects = {}, languageCode = 'en', sourceLanguage = null) {
-  // Convert Windows backslashes to forward slashes
-  // remove trailing slash
-  href = slash(href).replace(patterns.trailingSlash, '$1')
+module.exports = function findPage (href, pageMap, redirects) {
+  // remove any fragments
+  href = href.replace(/#.*$/, '')
 
-  // do an initial lookup on the path as-is
-  let page = pageMap[removeFragment(href)]
+  // find the page
+  const page = pageMap[href] || pageMap[redirects[href]]
   if (page) return page
 
-  // check all potential versions
-  const versionedPathsToCheck = [...new Set(allVersions.map(version => {
-    return getVersionedPathWithLanguage(href, version, languageCode)
-  }))]
+  // get the current language
+  const currentLang = getLanguageCode.test(href) ? href.match(getLanguageCode)[1] : 'en'
 
-  // get the first found path of the page (account for redirects)
-  let pathToPage = versionedPathsToCheck.find(path => {
-    path = redirects[path] || path
-    return pageMap[removeFragment(path)]
-  })
-
-  // need to account for redirects again
-  pathToPage = redirects[pathToPage] || pathToPage
-
-  // try finding the page again
-  page = pageMap[removeFragment(pathToPage)]
-
-  if (page) return page
-
-  if (process.env.NODE_ENV !== 'test' && languageCode === 'en') {
-    const error = sourceLanguage
-      ? `href not found in ${sourceLanguage} pages (no English fallback found)`
-      : 'href not found'
-
-    // if English page can't be found, throw an error
-    // because these errors should be surfaced and fixed right away
-    if (sourceLanguage === 'en') {
-      throw new Error(`${error}: ${href}`)
-    } else {
-      console.error(`${error}: ${href}`)
-    }
-  }
-
-  // if English page can't be found in tests, don't throw an error
-  // or the tests will stall
-  if (process.env.NODE_ENV === 'test' && languageCode === 'en') {
-    if (sourceLanguage === 'en') console.log(`href not found: ${href}`)
-    return null
-  }
-
-  // if localized page can't be found, fall back to English
-  // because localized content is not yet synced
-  if (languageCode !== 'en') {
-    // pass the source language so we can surface it in error messages
-    return findPage(href, pageMap, redirects, 'en', languageCode)
-  }
-}
-
-// some redirects include fragments
-// need to remove the fragment to find the page
-function removeFragment (path) {
-  if (!path) return
-
-  return path.replace(/#.*$/, '')
+  // try to fall back to English if the translated page can't be found
+  const englishHref = href.replace(`/${currentLang}/`, '/en/')
+  return pageMap[englishHref] || pageMap[redirects[englishHref]]
 }