GitHub Interview & Practice:

GitHub Interview & Practice: GitHub Workflow Questions and Hands-on CI/CD Projects

📅 Published: Feb 2026
⏱️ Estimated Reading Time: 22 minutes
🏷️ Tags: GitHub Actions, CI/CD, Automation, DevOps, Workflows, Deployment

Introduction: What GitHub Skills Are Interviewers Looking For?

When interviewers assess GitHub skills, they are not testing whether you can memorize commands. They are testing whether you understand how to collaborate, automate, and maintain code quality in a team environment.

The most valued GitHub skills in interviews are:

Understanding of Git branching strategies and pull request workflows
Ability to configure branch protection rules and enforce code review
Knowledge of GitHub Actions for CI/CD automation
Experience with secrets management and environment configuration
Familiarity with release processes and versioning

This guide covers the questions you are likely to face and the hands-on projects that will prove your skills.

Part 1: GitHub Workflow Questions

Foundational Questions

Q1: What is the difference between Git and GitHub?

Git is a version control system that runs locally on your computer. It tracks changes to files and manages your commit history. GitHub is a web-based platform that hosts Git repositories and adds collaboration features like pull requests, issue tracking, and CI/CD automation.

You can use Git without GitHub by cloning repositories locally and working entirely offline. But you cannot use GitHub's collaboration features without Git.

Q2: Explain the typical GitHub flow for contributing to a project.

The standard GitHub flow has seven steps:

Fork the repository to your own GitHub account
Clone your fork locally
Create a feature branch for your changes
Make your changes and commit them
Push your branch to your fork
Open a pull request to the original repository
After review and approval, merge the pull request

This workflow ensures that changes are reviewed before they reach the main branch and that multiple developers can work in parallel without conflicts.

Q3: What is a pull request and why is it important?

A pull request is a proposal to merge changes from one branch into another. It is the primary collaboration tool in GitHub.

Pull requests are important because they:

Provide a space for code review before changes are merged
Create a record of why changes were made
Enable automated tests to run before merging
Allow discussions about implementation details
Give the team visibility into what is being changed

Without pull requests, teams would need to coordinate merges through other channels, and there would be no systematic code review process.

Q4: How do you resolve merge conflicts in a pull request?

When a pull request has conflicts with the target branch, you resolve them by:

Checking out the feature branch locally: git checkout feature-branch
Pulling the latest changes from the target branch: git pull origin main
Resolving the conflicts in your code editor
Adding the resolved files: git add .
Committing the merge: git commit -m "Resolve merge conflicts"
Pushing the resolved branch: git push origin feature-branch

After pushing, the pull request will show that conflicts are resolved and the merge can proceed.

Branching and Collaboration Questions

Q5: What is your preferred branching strategy?

The most common answer is GitHub Flow: a single main branch with short-lived feature branches. Feature branches are created from main, developed, reviewed via pull requests, and merged back to main. This works well for continuous deployment.

For teams with scheduled releases, GitFlow may be appropriate. GitFlow uses main for production, develop for integration, feature/* branches for new work, release/* for preparing releases, and hotfix/* for urgent fixes.

The important point is not which strategy you choose, but that you can explain why you chose it for your team's context.

Q6: How do you ensure code quality in pull requests?

Code quality in pull requests is ensured through:

Branch protection rules that require pull request reviews before merging
Automated status checks that run tests, linters, and security scans
Code owners who automatically review changes to critical files
Requiring at least one approval before merging
Templates for pull request descriptions that capture testing and documentation

The goal is to create a process where quality is enforced automatically, not left to human memory.

Q7: What are branch protection rules and which ones do you use?

Branch protection rules are settings that restrict how branches can be modified. They are essential for maintaining stable main branches.

Key branch protection rules I use:

Require a pull request before merging
Require approvals (usually 1 or 2)
Dismiss stale approvals when new commits are pushed
Require status checks to pass before merging
Require branches to be up to date before merging
Include administrators in the rules
Disable force pushes
Disable branch deletion

These rules prevent direct pushes to main, ensure code review happens, and maintain a clean history.

Q8: How do you handle a critical bug that needs immediate fixing?

For critical bugs, I use a hotfix workflow:

Create a hotfix branch from the production tag: git checkout -b hotfix/critical-bug v1.0.0
Make the fix and commit it
Push the branch and open a pull request against main
Expedite review—this is an exception to normal processes
After merging to main, cherry-pick the fix to any release branches
Tag a new patch version: git tag -a v1.0.1
Deploy immediately

After the incident, I would review why the bug reached production and how to prevent similar issues.

GitHub Actions Questions

Q9: What is GitHub Actions and what problems does it solve?

GitHub Actions is a CI/CD platform built into GitHub. It solves the problem of manual, inconsistent deployment processes.

With GitHub Actions, you can:

Run tests automatically on every push
Build and package applications
Deploy to staging and production environments
Scan code for security vulnerabilities
Publish packages to registries
Generate release notes

Actions eliminates the need for separate CI/CD tools and keeps automation close to the code.

Q10: Explain the components of a GitHub Actions workflow.

A workflow has three main components:

Events: What triggers the workflow (push, pull_request, schedule, workflow_dispatch)
Jobs: Units of work that run on runners. Jobs can run in parallel or depend on each other.
Steps: Individual commands or actions within a job. Steps can run commands directly or use reusable actions.

The workflow is defined in a YAML file stored in .github/workflows/.

Q11: What is a matrix strategy and when would you use it?

A matrix strategy runs the same job with multiple configurations. You use it to test across different operating systems, language versions, or dependency versions.

Example matrix for testing Node.js on multiple versions:

strategy:
  matrix:
    node-version: [18, 20, 22]
    os: [ubuntu-latest, windows-latest]

This creates six parallel jobs, testing every combination. Matrix builds ensure your application works across all supported environments.

Q12: How do you manage secrets in GitHub Actions?

Secrets are stored in GitHub Settings under Secrets and variables. They are encrypted and only available to workflows during runs.

Best practices for secrets:

Never store secrets in code or commit them to repositories
Use environment-specific secrets for different deployment targets
Scope secrets to the minimum permissions needed
Rotate secrets regularly
Use OIDC authentication when possible to eliminate secrets entirely

In workflows, secrets are accessed with ${{ secrets.SECRET_NAME }}.

Q13: What is OIDC and why is it better than storing access keys?

OIDC (OpenID Connect) allows GitHub Actions to authenticate to cloud providers without storing any long-lived secrets. Instead of storing AWS access keys or Azure credentials, you configure a trust relationship between GitHub and your cloud provider.

OIDC is better because:

There are no secrets to rotate or manage
Credentials are temporary (typically 15-60 minutes)
Every run is auditable and tied to a specific workflow
Access can be finely controlled based on repository, branch, or environment

Many cloud providers now support OIDC for GitHub Actions, including AWS, Azure, and Google Cloud.

Security Questions

Q14: How do you prevent secrets from being committed to repositories?

Prevention requires multiple layers:

Pre-commit hooks that scan for secret patterns before commits are created
GitHub's secret scanning that alerts on detected secrets
Push protection that blocks commits containing known secret patterns
Education for team members on never committing secrets
Using environment variables and secrets managers instead of hardcoded values

The most important layer is pre-commit hooks, which prevent secrets from ever reaching the repository.

Q15: What is Dependabot and why is it important?

Dependabot is GitHub's automated dependency update tool. It scans your repository for outdated dependencies and opens pull requests to update them.

Dependabot is important because:

It keeps dependencies current with security patches
It reduces manual effort in maintaining dependencies
It creates a clear history of dependency updates
It can be configured to group minor updates together
It can run security audits and report vulnerabilities

In a secure development process, Dependabot should be enabled on all repositories.

Q16: How do you ensure only authorized people can deploy to production?

Ensuring authorized deployments involves:

Branch protection rules that prevent direct pushes to main
Environment protection rules that require approvals
Restricting who can approve deployments
Using deployment environments with separate secrets
Requiring status checks to pass
Maintaining audit logs of who approved and deployed

GitHub Environments provide these controls. You can require specific reviewers, restrict which branches can deploy, and set a time limit for approvals.

Part 2: Hands-on CI/CD Projects

Project 1: Simple CI Pipeline for a Node.js Application

This project creates a CI pipeline that runs tests and linting on every push and pull request.

Project Files

Create .github/workflows/ci.yml:

name: CI

on:
  push:
    branches: [ main, develop ]
  pull_request:
    branches: [ main ]

jobs:
  test:
    runs-on: ubuntu-latest
    
    strategy:
      matrix:
        node-version: [18, 20]
    
    steps:
      - uses: actions/checkout@v4
      
      - name: Use Node.js ${{ matrix.node-version }}
        uses: actions/setup-node@v4
        with:
          node-version: ${{ matrix.node-version }}
          cache: 'npm'
      
      - name: Install dependencies
        run: npm ci
      
      - name: Lint
        run: npm run lint
      
      - name: Test
        run: npm test
      
      - name: Upload coverage report
        uses: actions/upload-artifact@v4
        with:
          name: coverage-report-node-${{ matrix.node-version }}
          path: coverage/

What This Does

Runs on every push to main or develop
Also runs on every pull request targeting main
Tests against Node.js 18 and 20 in parallel
Caches npm dependencies for faster runs
Uploads test coverage reports as artifacts
Fails if linting or tests fail

How to Use

Add this file to your Node.js repository
Push to GitHub
View the Actions tab to see runs
Open a pull request to see the checks in action

Project 2: Multi-Environment Deployment Pipeline

This project creates a pipeline that deploys to staging on pushes to develop and to production on pushes to main, with manual approval for production.

Project Files

Create .github/workflows/deploy.yml:

name: Deploy

on:
  push:
    branches:
      - develop
      - main

jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: '18'
      - run: npm ci
      - run: npm test
      - run: npm run build
      - uses: actions/upload-artifact@v4
        with:
          name: build
          path: dist/

  deploy-staging:
    runs-on: ubuntu-latest
    needs: test
    if: github.ref == 'refs/heads/develop'
    environment: staging
    steps:
      - uses: actions/download-artifact@v4
        with:
          name: build
          path: dist/
      - name: Deploy to staging
        run: |
          # Replace with actual deployment command
          echo "Deploying to staging..."
          aws s3 sync dist/ s3://myapp-staging --delete
        env:
          AWS_ACCESS_KEY_ID: ${{ secrets.AWS_ACCESS_KEY_ID }}
          AWS_SECRET_ACCESS_KEY: ${{ secrets.AWS_SECRET_ACCESS_KEY }}

  deploy-production:
    runs-on: ubuntu-latest
    needs: test
    if: github.ref == 'refs/heads/main'
    environment: 
      name: production
      url: https://example.com
    steps:
      - uses: actions/download-artifact@v4
        with:
          name: build
          path: dist/
      - name: Deploy to production
        run: |
          # Replace with actual deployment command
          echo "Deploying to production..."
          aws s3 sync dist/ s3://myapp-production --delete
        env:
          AWS_ACCESS_KEY_ID: ${{ secrets.AWS_ACCESS_KEY_ID }}
          AWS_SECRET_ACCESS_KEY: ${{ secrets.AWS_SECRET_ACCESS_KEY }}

What This Does

Runs tests and builds on every push to develop or main
For pushes to develop, deploys to staging environment automatically
For pushes to main, requires manual approval before deploying to production
Uses the same built artifacts for both deployments
Shows deployment status and URL in GitHub UI

Setup Requirements

Create environments in repository Settings → Environments
Add staging and production environments
Configure required reviewers for production environment
Add AWS credentials as repository secrets

Project 3: Release Automation Pipeline

This project creates a pipeline that builds, creates a release, and publishes to npm when a tag is pushed.

Project Files

Create .github/workflows/release.yml:

name: Release

on:
  push:
    tags:
      - 'v*'

jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: '18'
      - run: npm ci
      - run: npm test

  create-release:
    runs-on: ubuntu-latest
    needs: test
    permissions:
      contents: write
    steps:
      - uses: actions/checkout@v4
      - name: Get version from tag
        id: version
        run: echo "VERSION=${GITHUB_REF#refs/tags/v}" >> $GITHUB_OUTPUT
      - name: Create Release
        uses: softprops/action-gh-release@v1
        with:
          generate_release_notes: true
          name: v${{ steps.version.outputs.VERSION }}
          draft: false
          prerelease: false

  publish-npm:
    runs-on: ubuntu-latest
    needs: create-release
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: '18'
          registry-url: 'https://registry.npmjs.org'
      - run: npm ci
      - run: npm publish
        env:
          NODE_AUTH_TOKEN: ${{ secrets.NPM_TOKEN }}

What This Does

Triggers when a tag starting with v is pushed
Runs tests to ensure quality
Creates a GitHub release with auto-generated notes
Publishes the package to npm registry
Uses the version number from the tag

How to Use

Update your version in package.json
Create and push a tag: git tag -a v1.0.0 -m "Version 1.0.0"
Push the tag: git push origin v1.0.0
Watch the release pipeline run

Project 4: Security Scanning Pipeline

This project adds security scanning to catch vulnerabilities before they reach production.

Project Files

Create .github/workflows/security.yml:

name: Security

on:
  push:
    branches: [ main, develop ]
  pull_request:
    branches: [ main ]
  schedule:
    - cron: '0 2 * * *'  # Daily at 2 AM

jobs:
  npm-audit:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: '18'
      - name: npm audit
        run: npm audit --production
      - name: npm audit fix (if needed)
        if: failure()
        run: npm audit fix

  codeql:
    runs-on: ubuntu-latest
    permissions:
      security-events: write
    steps:
      - uses: actions/checkout@v4
      - uses: github/codeql-action/init@v2
        with:
          languages: javascript
      - uses: github/codeql-action/analyze@v2

  snyk:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: snyk/actions/node@master
        env:
          SNYK_TOKEN: ${{ secrets.SNYK_TOKEN }}
        with:
          args: --severity-threshold=high

What This Does

Runs on every push and pull request
Also runs daily on a schedule to catch new vulnerabilities
Runs npm audit to check for vulnerable dependencies
Uses CodeQL to scan for code security issues
Uses Snyk to detect vulnerabilities with high severity
Fails the build if high-severity issues are found

GitHub Workflow Interview Preparation Checklist

Before a GitHub interview, ensure you can:

Explain your team's branching strategy and why you chose it
Walk through a pull request from creation to merge
Describe how you handle merge conflicts
Explain branch protection rules you have configured
Show a GitHub Actions workflow you have written
Explain how you manage secrets in CI/CD
Describe your release process and versioning strategy
Explain how you ensure code quality through automation

Practice Scenarios

Scenario 1: Emergency Production Fix

You are the on-call engineer. A critical bug was discovered in production. How do you fix it?

Create a hotfix branch from the production tag
Fix the bug and test locally
Open a pull request targeting main
Expedite review with the team
After merge, create a patch release tag
Deploy the hotfix
Cherry-pick the fix to develop if needed
Write a post-mortem to prevent recurrence

Scenario 2: Accidental Secret Commit

A developer accidentally committed an AWS access key to the repository. What do you do?

Immediately rotate the exposed key in AWS IAM
Remove the secret from Git history using BFG Repo-Cleaner
Force push the cleaned history
Check all forks for the exposed secret
Review who might have accessed the key
Set up pre-commit hooks to prevent recurrence

Scenario 3: Flaky Tests in CI

Your CI pipeline fails intermittently due to flaky tests. How do you address this?

Identify which tests are flaky by reviewing recent failures
Add retry logic for known flaky tests
Consider marking flaky tests as optional temporarily
Create a separate issue to fix the underlying problem
If the test cannot be fixed immediately, skip it but add a TODO comment
Track the issue and prioritize fixing the test infrastructure

Common Interview Mistakes to Avoid

Not understanding the difference between Git and GitHub
Not having experience with branch protection rules
Not knowing how to write a basic GitHub Actions workflow
Storing secrets in code or not knowing how secrets work
Not understanding the difference between continuous delivery and continuous deployment
Not having a strategy for handling merge conflicts
Not being able to explain your team's branching strategy

Summary

GitHub skills in interviews are tested through understanding of workflows, automation, and security. The most successful candidates can:

Explain their branching strategy with clear reasoning
Walk through a pull request from creation to merge
Write a simple GitHub Actions workflow
Discuss how they manage secrets and security
Describe their release process and versioning

The best way to prepare is to practice. Create repositories, set up workflows, configure branch protection, and release packages. Every practice project builds skills you can demonstrate in an interview.

Learn More

Practice GitHub workflows and CI/CD pipelines in guided labs at:
https://devops.trainwithsky.com/

SKY Tech – Explore Technology!

Search This Blog