GitHub Advanced Features Guide

What you will learn

• When to use custom Actions, matrix builds, and environment approvals
• How to deploy documentation or static sites with GitHub Pages
• How CODEOWNERS, Rulesets, and security features work
• What GitHub Projects can do for team planning

Start with a problem

You're choosing or configuring a Git hosting solution — whether self-hosting Gitea or comparing GitHub, GitLab, and Gitee features. You're not sure which option best fits your team's needs.

Start with a question

You are already using GitHub to host code. But you may have run into these situations:

• A CI step needs to be reused across multiple repositories — copying YAML each time is tedious
• You want documentation to auto-deploy to docs.yourcompany.com
• Specific directories need reviews from specific team members
• The main branch needs protection from accidental force pushes

GitHub has built-in features for all of these — but many teams stop at "push code" and never explore them.

One-sentence understanding

GitHub is more than Git hosting. It provides Actions (automation), Pages (hosting), Projects (planning), security scanning, and more — forming a complete collaboration loop around your repository.

Scenario 1: Reusing CI logic across projects

The problem

You have a build step that 10 projects need. Copying the same YAML everywhere means 10 places to update when something changes.

Solution: Custom Actions

A custom Action is a reusable building block, not a complete workflow:

# .github/actions/my-action/action.yml
name: "My Custom Action"
description: "A reusable custom action"
inputs:
  who-to-greet:
    description: "Who to greet"
    required: true
    default: "World"
outputs:
  time:
    description: "The time we greeted"
runs:
  using: "node20"
  main: "index.js"

The key insight: this lives in one repository and is referenced by many workflows. Update it in one place, and all consumers pick up the change.

Matrix builds: test across environments in parallel

jobs:
  test:
    strategy:
      matrix:
        os: [ubuntu-latest, macos-latest, windows-latest]
        node: [18, 20, 22]
    runs-on: ${{ matrix.os }}
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: ${{ matrix.node }}
      - run: npm test

This runs the same test suite 9 times (3 OS × 3 Node versions) in parallel. If one combination fails, you see it immediately.

Environment approvals: require a human before production

jobs:
  deploy:
    environment: production
    steps:
      - run: ./deploy.sh

With environment: production, you can require manual approval before deployment. This prevents accidental or unauthorized production releases.

Scenario 2: Deploying documentation as a website

Solution: GitHub Pages

GitHub Pages hosts static websites directly from your repository. Once configured, every push to main triggers a redeploy.

# .github/workflows/deploy.yml
jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - run: npm run build
      - uses: peaceiris/actions-gh-pages@v3
        with:
          github_token: ${{ secrets.GITHUB_TOKEN }}
          publish_dir: ./out

Custom domain

To use your own domain instead of your-org.github.io:

1. In repo Settings → Pages, enter your custom domain (e.g., docs.yourcompany.com)
2. Add a CNAME record pointing to your-org.github.io in your DNS provider

Scenario 3: Tracking work beyond issue lists

Solution: GitHub Projects

Projects give you kanban-style boards for tracking issues and PRs. Four views are available:

1. Table view: spreadsheet-like, good for batch editing
2. Board view: kanban columns (To Do, In Progress, Done)
3. Roadmap view: timeline for cross-project planning
4. Automation rules: auto-move cards when issue/PR state changes

A real example: a team's PRs move from "In Review" → "Approved" → "Done" automatically, no dragging required.

Scenario 4: Code changes keep missing the right reviewer

Solution: CODEOWNERS

Create a .github/CODEOWNERS file in your repository root:

# .github/CODEOWNERS
* @team-core
/src/api/ @team-api
/docs/ @team-docs
*.md @docs-maintainer

Now any PR that changes files under src/api/ automatically requests a review from @team-api. No manual reviewer assignment needed.

Rulesets: more flexible branch protection

Rulesets extend branch protection rules across multiple branches and tags:

• Lock repository configuration from being changed
• Require linear history (no merge commits)
• Restrict who can create or delete branches

Security features overview

Try it yourself

1. Extract a commonly used CI step into a custom Action in a separate repository, then reference it from your project workflow
2. Deploy your project documentation with GitHub Pages (start with the default your-org.github.io/repo domain)
3. Create a CODEOWNERS file and assign reviewers for different directories

Continue Learning

1. hosting/platform-comparison — Platform comparison
2. hosting/gitea-setup — Gitea self-hosted setup
3. github/github-flow-basics — GitHub Flow basics

Further reading

Keep going on the same topic:

• Gitea Self-Hosted Git Service
• Git Platform Comparison: GitHub vs GitLab vs Bitbucket
• Self-Hosted Git Service Comparison