← DevOps Hub
DevOps · Guide

GitHub

Repos, PRs, Actions integration, collaboration patterns.

— min read DevOps

Theory

GitHub is where code review, CI, and collaboration meet — protect main with branch rules and required checks.

GitHub is a cloud-hosted Git repository platform. Beyond storage, it provides pull requests for code review, Issues for bug tracking, Actions for CI/CD, Packages for artifact hosting, Pages for static site hosting, and Security features (Dependabot, code scanning). GitHub is the collaboration layer on top of Git's version control.

Pull requests (PRs) are the core collaboration unit. A PR proposes changes from a feature branch into a base branch (main/develop). Reviewers see a diff, leave inline comments, request changes, or approve. PR templates, required reviewer counts, and status checks (CI must pass) are enforced via branch protection rules in Settings → Branches.

Branch protection: require PR reviews before merging, require status checks to pass (CI green), prevent force-push to main, require signed commits. Enable "Require branches to be up to date" to prevent merging stale branches that miss recent commits. "Dismiss stale reviews" re-requires approval after new commits are pushed.

Code review best practices: keep PRs small (< 400 lines changed) for effective review; large PRs get rubber-stamped. Use GitHub's "Files changed" view to review; add line comments on specific code. Reviewers should check logic, edge cases, tests, and security — not just formatting (use linters for that). Approve only when you'd be comfortable owning this code.

Issues and project boards: Issues track bugs, features, and tasks. Labels categorize (bug, enhancement, good-first-issue). Milestones group issues for a release. GitHub Projects provides Kanban-style boards that link Issues and PRs. Automate: "closes #123" in a PR description auto-closes the linked issue on merge.

Releases and tags: a GitHub Release packages a git tag with release notes, changelog, and attached binaries. Tags mark specific commits — git tag v1.2.3 && git push origin v1.2.3. Semantic versioning: MAJOR.MINOR.PATCH. Automated release notes can be generated from PR titles using release-drafter or GitHub's built-in release notes generation.

GitHub CLI (gh): gh pr create opens a PR from the terminal; gh pr checkout PR_NUMBER checks out a PR locally for testing; gh run list shows recent Actions runs; gh repo clone org/repo clones without copying the URL. The CLI is faster than the web UI for repetitive tasks and scriptable for automation.

Architecture Diagram

Developer (git push)
         |
  GitHub repo + branch protection
         |
    +----+----+
    v         v
 Pull Request   GitHub Actions
    |              |
    v              v
 Code review    Build / test / deploy

Examples

yaml — workflow 
name: CI
on: [pull_request, push]
jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - run: npm ci && npm test
bash 
gh pr create --title "feat: add health check" --body "Fixes #42"
gh pr checks --watch

Interview Questions

Fork vs branch workflow?

Fork for external contributors (isolated copy); branch within repo for team members with shared access.

What makes a good PR?

Small diff, clear description, linked issue, tests, screenshots for UI, self-review checklist.

Branch protection essentials?

Require PR reviews, status checks, no force-push to main, signed commits if policy requires.

GitHub Actions vs Jenkins?

Actions is YAML-native, per-repo, tight GitHub integration; Jenkins is self-hosted, plugin ecosystem, multi-scm.

How do you manage secrets in Actions?

GitHub Secrets + OIDC to cloud — never echo secrets, use environments for prod approval gates.

CODEOWNERS purpose?

Auto-request reviews from team owning paths — ensures domain experts approve infra or API changes.

Best Practices

  • Treat GitHub config as code with review and CI validation.
  • Define SLOs and dashboards before production cutover.
  • Document rollback and ownership for on-call.
  • Use least privilege for credentials and secrets.

Common Mistakes

  • Running GitHub in prod without staging parity.
  • No monitoring on golden signals after changes.
  • Skipping backup/state export before major upgrades.
  • Alert fatigue without actionable runbooks.

Cheat Sheet

gh pr createOpen pull request
branch protectionRules on main
ActionsCI/CD in repo
CODEOWNERSAuto reviewers
EnvironmentsProd approval gates

Practical Exercises

Protected main

Enable branch protection requiring 1 review and green CI.

PR template

Add .github/pull_request_template.md with test plan section.

Actions cache

Speed up Node CI with actions/cache on node_modules.

← Git & Version Control

Related topics