GitHub Interview Questions

Technical interviews increasingly include questions about GitHub and collaborative development workflows. These questions test whether you can work effectively in a team environment, manage code professionally, and leverage GitHub's features for quality software delivery. This guide covers the most common GitHub-specific interview questions with thorough answers.

Repository and Collaboration Questions

What is the difference between Git and GitHub?

Git is a distributed version control system — a tool that runs on your local machine to track changes in files. GitHub is a cloud platform that hosts Git repositories and adds collaboration features like pull requests, issues, code reviews, and project management.

Think of it this way: Git is the engine, GitHub is the car with all the comfortable features. You can use Git without GitHub (via other hosts like GitLab or Bitbucket, or purely locally), but GitHub's value comes from its collaboration layer on top of Git.

Explain the Pull Request workflow.

A pull request is a proposal to merge changes from one branch into another. The workflow:

1. Create a feature branch from main
2. Make commits with your changes
3. Push the branch to GitHub
4. Open a Pull Request describing what you changed and why
5. Team members review the code, leave comments, request changes
6. CI/CD runs automated tests
7. After approval, the PR is merged into the target branch
8. The feature branch is deleted

PRs ensure every change is reviewed and tested before reaching the main codebase.

What are GitHub Actions and how have you used them?

GitHub Actions is an automation platform for CI/CD and workflow automation. I have used it to:

• Run test suites on every push and pull request
• Build and deploy applications to staging/production
• Enforce code quality with linting and type checking
• Automate release creation and changelog generation
• Run scheduled tasks like dependency updates

How do you handle merge conflicts in a team?

1. First, communicate with the person whose code conflicts with yours
2. Pull the latest changes from the target branch into your feature branch
3. Open the conflicted files and understand both versions
4. Resolve by choosing one version, combining both, or rewriting
5. Test thoroughly after resolution
6. Commit the resolution with a clear message

Prevention is better than cure — keep branches short-lived, pull main frequently, and communicate about file ownership.

What branch protection rules would you set for a production repository?

• Require at least 2 approving reviews
• Require all CI status checks to pass
• Require branches to be up-to-date with main before merging
• Dismiss stale reviews when new commits are pushed
• Require code owner review for critical paths
• Prevent force pushes
• Include administrators (no bypass)

Explain forking vs branching. When would you use each?

Branching is used within a single repository when you have push access. You create a branch, work on it, and merge via PR. This is the standard workflow for team members.

Forking creates an entirely separate copy of a repository under your account. Use forking when:

• Contributing to open source (you do not have push access)
• Experimenting without risk to the original
• Creating a derivative project

What is a GitHub Action workflow file structure?

Security Questions

How do you manage secrets in GitHub?

Never commit secrets to code. Use GitHub repository secrets (Settings → Secrets) which are encrypted and only exposed to GitHub Actions workflows via ${{ secrets.SECRET_NAME }}. For different environments (staging vs production), use environment-specific secrets.

What is a CODEOWNERS file?

CODEOWNERS automatically assigns reviewers based on which files a PR modifies. Example:

This ensures domain experts review changes to their areas.

Best Practices Questions

How do you write good commit messages?

Follow the conventional format: short imperative subject (50 chars), blank line, detailed body explaining why (not what). Reference issue numbers. Each commit should represent one logical change.

How do you structure a repository for a team?

Include: README with setup instructions, CONTRIBUTING.md with guidelines, .github templates for issues and PRs, proper .gitignore, LICENSE, branch protection, and CI/CD workflows. Use consistent naming conventions and code organization.

Describe your code review process.

I review for logic correctness, security implications, performance, readability, and adherence to team conventions. I leave constructive comments, distinguish between blockers and suggestions, test locally for complex changes, and respond to reviews within 24 hours.

Key Takeaways

GitHub interview questions test your understanding of collaborative development practices. Focus on demonstrating that you understand the complete workflow — from branching strategy through code review to deployment — and that you prioritize code quality, team communication, and security. Practice explaining these concepts clearly and concisely, using real examples from your experience.