LinkedIn

Interviews

🎯 Interview Guides 12 guides · updated 2026

Real questions and structured answers for data, cloud, and AI engineering interviews — including the system-design and GenAI rounds now showing up everywhere.

GitHub Interview Questions and Answers

These questions cover Git fundamentals, GitHub-specific features, and the CI/CD workflows that engineering teams rely on — commonly asked in DevOps, platform engineering, and full-stack developer interviews.

Git Fundamentals

Q1. What is the difference between Git and GitHub?

Git is a distributed version control system — a command-line tool for tracking changes in source code. It’s local-first: you can use Git without any network connection.

GitHub is a cloud platform built on top of Git. It adds:

Other Git hosting platforms: GitLab, Bitbucket, Azure DevOps Repos.

Q2. Explain the difference between git merge, git rebase, and git squash.

git merge — creates a merge commit that joins two branch histories. Preserves complete history including when branches diverged.

Terminal window
git checkout main
git merge feature/login
# Creates: o---o---o---o (main)
#                       |\
#                       | o---o (feature)
#                       |/
#                       M (merge commit)

git rebase — replays commits from one branch on top of another. Creates a linear history (no merge commit), but rewrites commit SHAs.

Terminal window
git checkout feature/login
git rebase main
# Before: main: A--B--C; feature: A--B--X--Y
# After:  feature: A--B--C--X'--Y' (new commits)

git squash — combines multiple commits into one before merging:

Terminal window
git merge --squash feature/login
git commit -m "Add login feature"  # All feature commits → one commit

Rule of thumb: rebase feature branches on main before merging (clean history); never rebase public/shared branches (rewrites history others depend on).

Q3. What is git cherry-pick and when would you use it?

git cherry-pick applies a specific commit from one branch to another without merging the entire branch:

Terminal window
# Apply commit abc1234 to current branch
git cherry-pick abc1234


# Apply a range of commits
git cherry-pick abc1234..def5678


# Cherry-pick without committing (staged only)
git cherry-pick --no-commit abc1234

Use cases:

Q4. What does git reset do and what are the differences between --soft, --mixed, and --hard?

git reset moves the HEAD pointer (and optionally the working tree and index) to a previous commit:

Terminal window
git reset --soft HEAD~1   # Undo commit, keep changes staged
git reset --mixed HEAD~1  # Undo commit, keep changes unstaged (default)
git reset --hard HEAD~1   # Undo commit, DISCARD all changes (destructive!)
FlagHEADIndex (staged)Working tree
--softMovedUnchangedUnchanged
--mixedMovedReset to HEADUnchanged
--hardMovedReset to HEADReset to HEAD

Warning: --hard permanently discards working changes. git reflog can rescue you if needed (commits are kept for ~90 days in reflog).

Q5. What is the difference between git fetch, git pull, and git clone?

Terminal window
git fetch origin          # Download all remote changes
git diff main origin/main # See what's different
git merge origin/main     # Merge when ready


# Equivalent shorthand (but less controlled)
git pull origin main

Best practice: git fetch + inspect + git merge gives more control than git pull directly.

GitHub Features

Q6. What is a Pull Request (PR) and what makes a good one?

A PR is a proposal to merge changes from one branch into another. It creates a space for code review, discussion, automated checks, and collaboration before changes land on the main branch.

What makes a good PR:

PR template example:

## What changed
Brief description of the change.


## Why
Link to issue or business context.


## Testing
- [ ] Unit tests added
- [ ] Manual testing steps


## Screenshots (for UI changes)

Q7. Explain GitHub Actions and how a CI/CD workflow is structured.

GitHub Actions is GitHub’s built-in CI/CD platform. Workflows are YAML files in .github/workflows/:

name: CI Pipeline


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


jobs:
  test:
    runs-on: ubuntu-latest


    steps:
      - uses: actions/checkout@v4


      - name: Set up Python
        uses: actions/setup-python@v5
        with:
          python-version: '3.12'


      - name: Install dependencies
        run: pip install -r requirements.txt


      - name: Run tests
        run: pytest --cov=src --cov-report=xml


      - name: Upload coverage
        uses: codecov/codecov-action@v4


  deploy:
    needs: test
    runs-on: ubuntu-latest
    if: github.ref == 'refs/heads/main'


    steps:
      - uses: actions/checkout@v4


      - name: Deploy to production
        env:
          DEPLOY_KEY: ${{ secrets.DEPLOY_KEY }}
        run: ./scripts/deploy.sh

Key concepts:

Q8. What is GitHub Dependabot and how does it improve security?

Dependabot automatically monitors your dependencies for known security vulnerabilities and outdated versions:

.github/dependabot.yml
version: 2
updates:
  - package-ecosystem: "pip"
    directory: "/"
    schedule:
      interval: "weekly"
    groups:
      dev-dependencies:
        patterns: ["pytest*", "black", "ruff"]

Dependabot PRs include a changelog and compatibility score based on how many other repos pass tests after this update.

Q9. What are GitHub Environments and how are they used for deployment control?

Environments add protection rules and secrets scoped to deployment targets:

jobs:
  deploy-prod:
    environment:
      name: production
      url: https://app.example.com
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - run: ./deploy.sh
        env:
          API_KEY: ${{ secrets.PROD_API_KEY }}  # Env-scoped secret

Protection rules you can configure per environment:

Branching Strategies

Q10. Compare Git Flow, GitHub Flow, and Trunk-Based Development.

Git Flow — two long-lived branches (main, develop) + feature/release/hotfix branches. Structured for scheduled releases.

GitHub Flow — only main is long-lived. Feature branches merge directly to main via PR; deploy from main.

feature/search → PR → main → deploy

Trunk-Based Development — everyone commits to main (trunk) daily. Feature flags hide in-progress features.

Most modern web teams use GitHub Flow or Trunk-Based Development. Git Flow is declining in favor of simpler models.

Q11. What is git stash and when is it useful?

git stash saves uncommitted changes (staged and unstaged) to a temporary stack so you can switch branches or apply another change with a clean working directory:

Terminal window
# Save current changes
git stash push -m "WIP: login form validation"


# List stashes
git stash list
# stash@{0}: WIP: login form validation
# stash@{1}: On feature/search: temp debug logs


# Apply and remove top stash
git stash pop


# Apply without removing (keep in stash)
git stash apply stash@{1}


# Stash only unstaged changes
git stash push --keep-index


# Drop a specific stash
git stash drop stash@{0}


# Create a branch from a stash
git stash branch feature/login stash@{0}

Q12. How do you recover a deleted branch or accidentally reset commit in Git?

Git keeps a local log of where HEAD has pointed — the reflog:

Terminal window
# See the history of HEAD movements
git reflog
# abc1234 (HEAD -> main) HEAD@{0}: reset: moving to HEAD~3
# def5678 HEAD@{1}: commit: Add user authentication
# 789abcd HEAD@{2}: commit: Fix login bug


# Recover by creating a branch at the lost commit
git checkout -b recovered-branch def5678


# Or reset main back to the commit before the bad reset
git reset --hard def5678

Reflog entries are kept for 90 days by default. Remote branches that were deleted can be recovered from teammates’ repos or GitHub’s 30-day restoration window (for non-force-deleted branches).

GitHub Security

Q13. What is branch protection and what rules should every production branch have?

Branch protection rules prevent direct pushes to critical branches and enforce review standards:

Essential rules for main/production branches:

Q14. What is GitHub’s secret scanning and how does it prevent credential leaks?

GitHub Secret Scanning automatically scans all commits for known secret patterns (API keys, tokens, credentials) from 100+ service providers:

Best practice: use .gitignore to exclude .env files, use GitHub Actions secrets for CI credentials, and enable push protection for all repositories.