GitHub Interview Questions

Common questions about GitHub, CI/CD, and collaboration workflows. These come up in DevOps, backend, and full-stack engineering interviews.

1. What is the difference between Git and GitHub?

Git is the open-source distributed version control system - it tracks file changes, manages branches, and stores history locally on your machine. GitHub is a cloud hosting platform built on top of Git that adds collaboration features: pull requests, code review, Issues, Actions (CI/CD), wikis, project boards, and security scanning. You can use Git without GitHub (self-hosted GitLab, Bitbucket, or no remote at all), but GitHub requires Git. Other comparable platforms are GitLab and Bitbucket.

2. What is a Pull Request and how does it differ from a git merge?

A Pull Request is a GitHub UI feature that wraps a proposed merge with a discussion thread, code review, and CI checks. It is a collaboration workflow, not a Git primitive. A git merge is the underlying Git operation that actually integrates branches - it can be done directly on the command line with no review. PRs are mandatory in team environments because they enforce review policies, create an audit trail, trigger automated checks, and allow discussion before code lands in the main branch.

3. What are branch protection rules and why are they important?

Branch protection rules (Settings → Branches → Protection rules) prevent direct pushes to critical branches like main. Common rules: require PR reviews before merging (N approvals), require status checks (CI must pass), require branches to be up to date before merging, restrict who can push, require signed commits, and prevent force pushes. They enforce team standards automatically rather than relying on discipline, preventing accidental breakage of the main branch and ensuring every change goes through review and CI.

4. How do GitHub Actions compare to Jenkins?

GitHub Actions is GitHub-native CI/CD: zero setup, YAML-based workflows versioned with the code, generous free tier (2000 min/month), and a massive marketplace of pre-built actions. Jenkins is a self-hosted, plugin-based Java CI server with maximum flexibility but significant operational overhead (you manage the server, plugins, agents). Actions is better for most teams starting fresh; Jenkins is preferred when you need deep customization, have an existing investment, need to run on-prem for security reasons, or require pipelines that span multiple SCM systems.

5. What is GitHub Packages and how is it used?

GitHub Packages is a package hosting service integrated with GitHub repos and Actions. It supports npm, Docker (Container Registry at ghcr.io), Maven, NuGet, RubyGems, and Gradle. You publish artifacts (Docker images, npm packages) to it as part of your CI pipeline, then pull them in deployments. The advantage is tight integration - packages are linked to repos, access is controlled by repository permissions, and you can reference package versions directly in Actions workflows without managing a separate registry.

6. How do you prevent secrets from being exposed in a GitHub repo?

Best practices: (1) Never commit secrets - use GitHub Secrets (encrypted, not visible in logs) for Actions. (2) Add .env to .gitignore before the first commit. (3) Enable GitHub secret scanning - it automatically detects leaked API keys, tokens, and credentials from 100+ providers and alerts you. (4) Use environment-scoped secrets so production credentials are only available to deployment workflows. (5) If a secret is leaked, rotate it immediately - assume it is compromised. (6) Use tools like git-secrets, truffleHog, or Gitleaks in pre-commit hooks.

7. What is the CODEOWNERS file and how does it work?

The CODEOWNERS file (located at .github/CODEOWNERS, CODEOWNERS, or docs/CODEOWNERS) maps file paths to GitHub users or teams who own that code. When a PR touches an owned file, GitHub automatically requests reviews from the designated owners. Format: glob patterns followed by @user or @org/team. Combined with branch protection's "Require review from Code Owners" setting, this enforces that relevant experts always review changes in their area - preventing a frontend developer from merging infrastructure changes without DevOps sign-off.

8. What are GitHub Environments and when would you use them?

GitHub Environments (Settings → Environments) are named deployment targets (staging, production, etc.) with their own secrets, variables, and protection rules. Environment-scoped secrets override repo-level secrets for jobs targeting that environment. Protection rules include: required reviewers (a human must approve the deployment), wait timers (delay before deployment), and branch restrictions (only certain branches can deploy to production). Use them to model your staging/prod pipeline - the production environment can require manual approval and have tighter secrets access than staging.

9. How does GitHub handle monorepos for CI/CD?

GitHub Actions has path filters to only trigger workflows when relevant files change: use `on.push.paths` and `on.pull_request.paths` to scope triggers to specific directories. For example, a change in `packages/api/` only triggers the API workflow. For larger monorepos, tools like Turborepo or Nx integrate with Actions to run only affected package tests. The `actions/cache` action is critical in monorepos to share build caches across jobs and runs. Another pattern is using `workflow_call` to define per-package reusable workflows called from a root orchestrator workflow.

10. What is GitHub Dependabot and how does it help with security?

Dependabot is GitHub's automated dependency management tool. It has two main modes: Dependabot alerts scan your dependency manifest (package.json, requirements.txt, etc.) against the GitHub Advisory Database and alert you to known vulnerabilities (CVEs). Dependabot security updates automatically open PRs to bump vulnerable dependencies to patched versions. Dependabot version updates (configured via .github/dependabot.yml) can also keep all dependencies up-to-date on a schedule, not just vulnerable ones. It supports npm, pip, Maven, Gradle, Cargo, Go modules, and more.